[jira] [Updated] (IGNITE-7133) Web console: Improve ignite icon service interface to extendable

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7133:
-
Fix Version/s: 2.4

> Web console: Improve ignite icon service interface to extendable
> 
>
> Key: IGNITE-7133
> URL: https://issues.apache.org/jira/browse/IGNITE-7133
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>




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

[jira] [Commented] (IGNITE-7133) Web console: Improve ignite icon service interface to extendable

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin commented on IGNITE-7133:
--

[~kuaw26] added, pls review it

> Web console: Improve ignite icon service interface to extendable
> 
>
> Key: IGNITE-7133
> URL: https://issues.apache.org/jira/browse/IGNITE-7133
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
>




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

[jira] [Assigned] (IGNITE-7133) Web console: Improve ignite icon service interface to extendable

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-7133:


Assignee: Alexey Kuznetsov  (was: Dmitriy Shabalin)

> Web console: Improve ignite icon service interface to extendable
> 
>
> Key: IGNITE-7133
> URL: https://issues.apache.org/jira/browse/IGNITE-7133
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
>




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

[jira] [Commented] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command

[Roman Kondakov (JIRA)]

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

Roman Kondakov commented on IGNITE-7044:


[~dmagda],

IMHO yes, they have quite similar semantics. But they used for the different 
types of queries - SQL and DDL. [~vozerov], what do you think?

> SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
> -
>
> Key: IGNITE-7044
> URL: https://issues.apache.org/jira/browse/IGNITE-7044
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> Add a documentation for the PARALLEL option in the CREATE INDEX command.



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

[jira] [Created] (IGNITE-7133) Web console: Improve ignite icon service interface to extendable

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-7133:


 Summary: Web console: Improve ignite icon service interface to 
extendable
 Key: IGNITE-7133
 URL: https://issues.apache.org/jira/browse/IGNITE-7133
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin






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

[jira] [Assigned] (IGNITE-7121) visorcmd: there is no output for last command in batch mode in case of using -nq option

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7121:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> visorcmd: there is no output for last command in batch mode in case of using 
> -nq option
> ---
>
> Key: IGNITE-7121
> URL: https://issues.apache.org/jira/browse/IGNITE-7121
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.3
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> To reproduce try to execute visorcmd in batch mode 
> {code}
> ignitevisorcmd.bat "-nq -b=commands.visor"
> {code}
> with command file
> {code}
> open -cpath=config/your-config.xml
> config
> {code}
> output of 'config' command will not displayed



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

[jira] [Commented] (IGNITE-7121) visorcmd: there is no output for last command in batch mode in case of using -nq option

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-7121:
---

Fixed reading of last command in batch mode.

> visorcmd: there is no output for last command in batch mode in case of using 
> -nq option
> ---
>
> Key: IGNITE-7121
> URL: https://issues.apache.org/jira/browse/IGNITE-7121
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.3
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>
> To reproduce try to execute visorcmd in batch mode 
> {code}
> ignitevisorcmd.bat "-nq -b=commands.visor"
> {code}
> with command file
> {code}
> open -cpath=config/your-config.xml
> config
> {code}
> output of 'config' command will not displayed



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

[jira] [Created] (IGNITE-7131) Document Web Console deployment in Kubernetes

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7131:
---

 Summary: Document Web Console deployment in Kubernetes
 Key: IGNITE-7131
 URL: https://issues.apache.org/jira/browse/IGNITE-7131
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.5
Reporter: Denis Magda


The ticket is inspired by the following topic:
http://apache-ignite-users.70518.x6.nabble.com/Web-Console-on-Kubernetes-Cluster-td18591.html

It will be great to put together a documentation about Web Console deployment 
on Kubernetes.



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

[jira] [Updated] (IGNITE-7131) Document Web Console deployment in Kubernetes

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7131:

Component/s: documentation

> Document Web Console deployment in Kubernetes
> -
>
> Key: IGNITE-7131
> URL: https://issues.apache.org/jira/browse/IGNITE-7131
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.5
>Reporter: Denis Magda
>
> The ticket is inspired by the following topic:
> http://apache-ignite-users.70518.x6.nabble.com/Web-Console-on-Kubernetes-Cluster-td18591.html
> It will be great to put together a documentation about Web Console deployment 
> on Kubernetes.



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

[jira] [Assigned] (IGNITE-7121) visorcmd: there is no output for last command in batch mode in case of using -nq option

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7121:
-

Assignee: Vasiliy Sisko

> visorcmd: there is no output for last command in batch mode in case of using 
> -nq option
> ---
>
> Key: IGNITE-7121
> URL: https://issues.apache.org/jira/browse/IGNITE-7121
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.3
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>
> To reproduce try to execute visorcmd in batch mode 
> {code}
> ignitevisorcmd.bat "-nq -b=commands.visor"
> {code}
> with command file
> {code}
> open -cpath=config/your-config.xml
> config
> {code}
> output of 'config' command will not displayed



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

[jira] [Commented] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-6999:
---

Removed spring logs in quiet batch mode.

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



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

[jira] [Assigned] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-6999:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



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

[jira] [Updated] (IGNITE-7130) Annotate message related code as "generated by MessageCodeGenerator"

[Alexander Belyak (JIRA)]

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

Alexander Belyak updated IGNITE-7130:
-
Summary: Annotate message related code as "generated by 
MessageCodeGenerator"  (was: Simplify message related code in communication)

> Annotate message related code as "generated by MessageCodeGenerator"
> 
>
> Key: IGNITE-7130
> URL: https://issues.apache.org/jira/browse/IGNITE-7130
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Minor
>
> All code, auto generated in 
> org.apache.ignite.plugin.extensions.communication.Message implementation by 
> MessageCodeGenerator should be annotated with link to generator.



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

[jira] [Created] (IGNITE-7130) Simplify message related code in communication

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7130:


 Summary: Simplify message related code in communication
 Key: IGNITE-7130
 URL: https://issues.apache.org/jira/browse/IGNITE-7130
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.1
Reporter: Alexander Belyak
Priority: Minor


All code, auto generated in 
org.apache.ignite.plugin.extensions.communication.Message implementation by 
MessageCodeGenerator should be annotated with link to generator.



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

[jira] [Commented] (IGNITE-4452) Web console: add execution time to results panel on Queries screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4452:


Will be tested in IGNITE-4454

> Web console: add execution time to results panel on Queries screen
> --
>
> Key: IGNITE-4452
> URL: https://issues.apache.org/jira/browse/IGNITE-4452
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Trivial
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> I think it may be useful to know query last execution time, especially if we 
> have a Refresh rate possibility.



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

[jira] [Assigned] (IGNITE-6976) Visor CMD: Add ability to put/get/remove data to caches via command line Visor.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-6976:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Visor CMD: Add ability to put/get/remove data to caches via command line 
> Visor.
> ---
>
> Key: IGNITE-6976
> URL: https://issues.apache.org/jira/browse/IGNITE-6976
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>




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

[jira] [Commented] (IGNITE-6976) Visor CMD: Add ability to put/get/remove data to caches via command line Visor.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6976:


Let use a java.lang.String as a default value for type for Key and Value and 
also implement the simple format as you can see below
In this case, using of 'modify' command will become more convenience 
For example
modify -cache=@c0 -put 1  -  will put into the cache @c0 key "1"(String) 
with value "1"(String)
modify -cache=@c0 -get 1  - will return from cache @c0 the value for key 
"1"(String)
modify  -cache=@c0 -remove 1  - will remove from cache @c0 by key 
"1"(String)

> Visor CMD: Add ability to put/get/remove data to caches via command line 
> Visor.
> ---
>
> Key: IGNITE-6976
> URL: https://issues.apache.org/jira/browse/IGNITE-6976
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>




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

[jira] [Assigned] (IGNITE-4835) Add ability to start rebalancing from management console

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-4835:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Add ability to start rebalancing from management console
> 
>
> Key: IGNITE-4835
> URL: https://issues.apache.org/jira/browse/IGNITE-4835
> Project: Ignite
>  Issue Type: New Feature
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>Assignee: Vasiliy Sisko
>Priority: Minor
>
> Management console should allow for starting rebalancing manually.



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

[jira] [Commented] (IGNITE-4835) Add ability to start rebalancing from management console

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4835:


Please fix the following
{code}
visor> cache -rebalance -c=dsfgsdfghsdfgdfgh
[WARN ] Re-balance partitions of system cache is not allowed: dsfgsdfghsdfgdfgh

visor> cache -reset -c=dsfgsdfghsdfgdfgh
[WARN ] Reset metrics of system cache is not allowed: dsfgsdfghsdfgdfgh
{code}
It is incorrect to print out "Re-balance partitions of system cache is not 
allowed" in case of non-existing cache 

> Add ability to start rebalancing from management console
> 
>
> Key: IGNITE-4835
> URL: https://issues.apache.org/jira/browse/IGNITE-4835
> Project: Ignite
>  Issue Type: New Feature
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
>Priority: Minor
>
> Management console should allow for starting rebalancing manually.



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

[jira] [Comment Edited] (IGNITE-7055) Text query for a particular field not working

[Roman Shtykh (JIRA)]

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

Roman Shtykh edited comment on IGNITE-7055 at 12/6/17 11:34 PM:


[~vkulichenko] Field names are case sensitive 
(https://wiki.apache.org/lucene-java/LuceneFAQ)
Therefore we have to upper-case them to match Ignite index names. Hence, the 
solution I provided.


was (Author: roman_s):
[~vkulichenko] Field names are case sensitive 
(https://wiki.apache.org/lucene-java/LuceneFAQ)

> Text query for a particular field not working
> -
>
> Key: IGNITE-7055
> URL: https://issues.apache.org/jira/browse/IGNITE-7055
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Roman Shtykh
>
> Lucene queries allow to specify a specific field name to search in [1], 
> however this doesn't seem to work in latest versions of Ignite.
> To reproduce, modify {{CacheQueryExample#textQuery}} to use Lucene field 
> expression:
> {code}
> QueryCursor> masters =
> cache.query(new TextQuery(Person.class, "resume:Master"));
> {code}
> This query returns empty result.
> [1] 
> http://lucene.apache.org/core/5_5_2/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fields



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

[jira] [Comment Edited] (IGNITE-7055) Text query for a particular field not working

[Roman Shtykh (JIRA)]

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

Roman Shtykh edited comment on IGNITE-7055 at 12/6/17 11:33 PM:


In _GridLuceneIndex_ _IndexWriter_ is build with a _StandardAnalyzer_, which 
applies _LowerCaseFilter_ to query terms. It makes queries case-insensitive. 
However, field names are case-sensitive, and in Ignite indexes are upper-cased. 
Therefore _resume:Master_ won't be found, but _RESUME:Master_ will be found.
I propose to convert all queries to upper case. That will make Ignite indexes 
searcheable when a field is specified in a Lucene query, and won't effect the 
current search behavior.


was (Author: roman_s):
In _GridLuceneIndex_ _IndexWriter_ is build with a _StandardAnalyzer_, which 
applies _LowerCaseFilter_ to query terms. It makes queries case-insensitive. 
However, fields are case-sensitive, and in Ignite indexes are upper-cased. 
Therefore _resume:Master_ won't be found, but _RESUME:Master_ will be found.
I propose to convert all queries to upper case. That will make Ignite indexes 
searcheable when a field is specified in a Lucene query, and won't effect the 
current search behavior.

> Text query for a particular field not working
> -
>
> Key: IGNITE-7055
> URL: https://issues.apache.org/jira/browse/IGNITE-7055
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Roman Shtykh
>
> Lucene queries allow to specify a specific field name to search in [1], 
> however this doesn't seem to work in latest versions of Ignite.
> To reproduce, modify {{CacheQueryExample#textQuery}} to use Lucene field 
> expression:
> {code}
> QueryCursor> masters =
> cache.query(new TextQuery(Person.class, "resume:Master"));
> {code}
> This query returns empty result.
> [1] 
> http://lucene.apache.org/core/5_5_2/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fields



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

[jira] [Commented] (IGNITE-7055) Text query for a particular field not working

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-7055:
--

[~vkulichenko] Field names are case sensitive 
(https://wiki.apache.org/lucene-java/LuceneFAQ)

> Text query for a particular field not working
> -
>
> Key: IGNITE-7055
> URL: https://issues.apache.org/jira/browse/IGNITE-7055
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Roman Shtykh
>
> Lucene queries allow to specify a specific field name to search in [1], 
> however this doesn't seem to work in latest versions of Ignite.
> To reproduce, modify {{CacheQueryExample#textQuery}} to use Lucene field 
> expression:
> {code}
> QueryCursor> masters =
> cache.query(new TextQuery(Person.class, "resume:Master"));
> {code}
> This query returns empty result.
> [1] 
> http://lucene.apache.org/core/5_5_2/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fields



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

[jira] [Commented] (IGNITE-7055) Text query for a particular field not working

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-7055:
-

[~roman_s], just to clarify: how does Lucene typically behave in this case? Are 
field names case sensitive there or not?

> Text query for a particular field not working
> -
>
> Key: IGNITE-7055
> URL: https://issues.apache.org/jira/browse/IGNITE-7055
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Roman Shtykh
>
> Lucene queries allow to specify a specific field name to search in [1], 
> however this doesn't seem to work in latest versions of Ignite.
> To reproduce, modify {{CacheQueryExample#textQuery}} to use Lucene field 
> expression:
> {code}
> QueryCursor> masters =
> cache.query(new TextQuery(Person.class, "resume:Master"));
> {code}
> This query returns empty result.
> [1] 
> http://lucene.apache.org/core/5_5_2/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fields



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

[jira] [Updated] (IGNITE-6341) Use direct IO or libaio for file page store and WAL where applicable

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6341:

Fix Version/s: 2.4

> Use direct IO or libaio for file page store and WAL where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> Need try to use direct IO or libaio for WAL writer thread because once data 
> buffer is serialized, we can write it as disk pages (this will also make it 
> easier if we decide to open file as a block device).



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

[jira] [Issue Comment Deleted] (IGNITE-7109) .NET: Thin client: Async cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7109:
---
Comment: was deleted

(was: Methods based on {{SocketAsyncEventArgs}} are said to be the most 
performant:  
https://stackoverflow.com/questions/24174423/c-sharp-socket-performance-with-net-4-5-async-vs-async-vs-begin)

> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Commented] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7044:
-

[~rkondakov],

How is this option related to the generic query parallelism level?
https://apacheignite-sql.readme.io/docs/performance-and-debugging#query-parallelism

In my understanding, it's absolutely the same feature. The only difference is 
that {{CacheConfiguration.queryParallelism}} is used a default value for all 
the indexes while {{PARALLEL}} option makes it possible to adjust the level for 
a concrete index.

> SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
> -
>
> Key: IGNITE-7044
> URL: https://issues.apache.org/jira/browse/IGNITE-7044
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> Add a documentation for the PARALLEL option in the CREATE INDEX command.



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

[jira] [Assigned] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7044:
---

Assignee: Roman Kondakov  (was: Denis Magda)

> SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
> -
>
> Key: IGNITE-7044
> URL: https://issues.apache.org/jira/browse/IGNITE-7044
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> Add a documentation for the PARALLEL option in the CREATE INDEX command.



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

[jira] [Commented] (IGNITE-7109) .NET: Thin client: Async cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7109:


Methods based on {{SocketAsyncEventArgs}} are said to be the most performant:  
https://stackoverflow.com/questions/24174423/c-sharp-socket-performance-with-net-4-5-async-vs-async-vs-begin

> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Resolved] (IGNITE-6830) Document how to set up secured channel for JDBC Client Driver

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-6830.
-
Resolution: Fixed

> Document how to set up secured channel for JDBC Client Driver
> -
>
> Key: IGNITE-6830
> URL: https://issues.apache.org/jira/browse/IGNITE-6830
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.4
>
>
> JDBC Client Driver allows opening secured connections to a cluster by means 
> of {{SecurityCredentialsProvider}}. This features needs to be documented:
> https://apacheignite-sql.readme.io/docs/jdbc-client-driver



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

[jira] [Commented] (IGNITE-6830) Document how to set up secured channel for JDBC Client Driver

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6830:
-

[~pgarg], thanks for writing this vivid and professional documentation. Looks 
good to me, closing the ticket.

> Document how to set up secured channel for JDBC Client Driver
> -
>
> Key: IGNITE-6830
> URL: https://issues.apache.org/jira/browse/IGNITE-6830
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.4
>
>
> JDBC Client Driver allows opening secured connections to a cluster by means 
> of {{SecurityCredentialsProvider}}. This features needs to be documented:
> https://apacheignite-sql.readme.io/docs/jdbc-client-driver



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

[jira] [Closed] (IGNITE-6830) Document how to set up secured channel for JDBC Client Driver

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6830.
---

> Document how to set up secured channel for JDBC Client Driver
> -
>
> Key: IGNITE-6830
> URL: https://issues.apache.org/jira/browse/IGNITE-6830
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.4
>
>
> JDBC Client Driver allows opening secured connections to a cluster by means 
> of {{SecurityCredentialsProvider}}. This features needs to be documented:
> https://apacheignite-sql.readme.io/docs/jdbc-client-driver



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

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-602:


[~SomeFire] I still see StackOverflowError in Ignite Basic suite. 
https://ci.ignite.apache.org/viewLog.html?buildId=980109=buildResultsDiv=Ignite20Tests_IgniteBasic

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.4
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



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

[jira] [Created] (IGNITE-7129) Implement Multilayer Perceptron

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-7129:


 Summary: Implement Multilayer Perceptron
 Key: IGNITE-7129
 URL: https://issues.apache.org/jira/browse/IGNITE-7129
 Project: Ignite
  Issue Type: New Feature
Reporter: Artem Malykh
Assignee: Artem Malykh






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

[jira] [Commented] (IGNITE-7114) CPP: C++ node can't start without java examples folder

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7114:


[~isapego] source release logic looks good to me.
But for binary releases I would check {{libs\ignite-core-x.y.z.jar}} presence 
instead of {{ignite-indexing}} and {{ignite-spring}} folders, because that is 
the main JAR file, and you can run Ignite without indexing or spring.

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Commented] (IGNITE-7015) SQL: index should be updated only when relevant values changed

[Roman Kondakov (JIRA)]

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

Roman Kondakov commented on IGNITE-7015:


[~vozerov] please review, tests are OK.

> SQL: index should be updated only when relevant values changed
> --
>
> Key: IGNITE-7015
> URL: https://issues.apache.org/jira/browse/IGNITE-7015
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> See {{GridH2Table.update}} method. Whenever value is updated, we propagate it 
> to all indexes. Consider the following case:
> 1) Old row is not null, so this is "update", not "create".
> 2) Link hasn't changed
> 3) Indexed fields haven't changed
> If all conditions are met, we can skip index update completely, as state 
> before and after will be the same. This is especially important when 
> persistence is enabled because currently we generate unnecessary dirty pages 
> what increases IO pressure.
> Suggested fix:
> 1) Iterate over index columns, skipping key and affinity columns (as they are 
> guaranteed to be the same);
> 2) Compare relevant index columns of both old and new rows
> 3) If all columns are equal, do nothing.
> Fields should be read through {{GridH2KeyValueRowOnheap#getValue}}, because 
> in this case we will re-use value cache transparently.



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

[jira] [Comment Edited] (IGNITE-7109) .NET: Thin client: Async cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7109 at 12/6/17 5:36 PM:
-

Benchmarks added. Current async implementation ({{BeginSend}}/{{BeginReceive}}) 
is 30% slower than master ({{Send}}/{{Receive}}).
This appears to be a common issue: 
https://stackoverflow.com/questions/9915101/performance-of-receiveasync-vs-beginreceive
We should try performing a request synchronously and then falling back to async 
if response is not quickly available (see comments to the accepted answer).


was (Author: ptupitsyn):
Benchmarks added. Current async implementation ({{BeginSend}}/{{BeginReceive}}) 
is 30% slower than master.
This appears to be a common issue: 
https://stackoverflow.com/questions/9915101/performance-of-receiveasync-vs-beginreceive
We should try performing a request synchronously and then falling back to async 
if response is not quickly available (see comments to the accepted answer).

> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Commented] (IGNITE-7109) .NET: Thin client: Async cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7109:


Benchmarks added. Current async implementation ({{BeginSend}}/{{BeginReceive}}) 
is 30% slower than master.
This appears to be a common issue: 
https://stackoverflow.com/questions/9915101/performance-of-receiveasync-vs-beginreceive
We should try performing a request synchronously and then falling back to async 
if response is not quickly available (see comments to the accepted answer).

> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Commented] (IGNITE-7083) Reduce memory usage of CachePartitionFullCountersMap

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-7083:
---

Hi [~sunnychanclsa]

Thanks for investigation.

The optimization won't give you much, because CachePartitionFullCountersMap 
will contain zeroes only if no cache updates were done.

Apache Ignite community is aware of heap consumption issues by CPFCM and other 
cache/exchange related data structures if number of caches/partitions is quite 
large.

I'm going soon to create a bunch of tickets related to several optimization 
that needs to be done on the subject.



> Reduce memory usage of CachePartitionFullCountersMap
> 
>
> Key: IGNITE-7083
> URL: https://issues.apache.org/jira/browse/IGNITE-7083
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
> Environment: Any
>Reporter: Sunny Chan
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> The Cache Partition Exchange Manager kept a copy of the already completed 
> exchange. However, we have found that it uses a significant amount of memory. 
> Upon further investigation using heap dump we have found that a large amount 
> of memory is used by the CachePartitionFullCountersMap. We have also observed 
> in most cases, these maps contains only 0s.
> Therefore I propose an optimization for this: Initially the long arrays to 
> store initial update counter and update counter in the CPFCM will be null, 
> and when you get the value and see these tables are null then we will return 
> 0 for the counter. We only allocate the long arrays when there is any 
> non-zero updates to the the map.
> In our tests, the amount of heap used by GridCachePartitionExchangeManager 
> was around 70MB (67 copies of these CPFCM), after we apply the optimization 
> it drops to around 9MB.



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

[jira] [Resolved] (IGNITE-7124) .NET: Thin client: Cache benchmark

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7124.

Resolution: Fixed

> .NET: Thin client: Cache benchmark
> --
>
> Key: IGNITE-7124
> URL: https://issues.apache.org/jira/browse/IGNITE-7124
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add a benchmark to see how thin client compares to full mode, see existing 
> {{PutBenchmark}} as an example.



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

[jira] [Commented] (IGNITE-7124) .NET: Thin client: Cache benchmark

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7124:


Benchmarks added: {{ThinClientGetBenchmark}}, {{ThinClientPutBenchmark}}

Results (op/s):
{code}
Put: 66K
ThinPut:  13K

Get: 110K
ThinGet:  14K
{code}

Merged to master: {{9813c626b3ac49e99d8b404aec44992e48dd1fed}}.

> .NET: Thin client: Cache benchmark
> --
>
> Key: IGNITE-7124
> URL: https://issues.apache.org/jira/browse/IGNITE-7124
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add a benchmark to see how thin client compares to full mode, see existing 
> {{PutBenchmark}} as an example.



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

[jira] [Comment Edited] (IGNITE-7124) .NET: Thin client: Cache benchmark

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7124 at 12/6/17 5:17 PM:
-

Benchmarks added: {{ThinClientGetBenchmark}}, {{ThinClientPutBenchmark}}

Results (op/s):
{code}
Put:  66K
ThinPut:  13K

Get:  110K
ThinGet:  14K
{code}

Merged to master: {{9813c626b3ac49e99d8b404aec44992e48dd1fed}}.


was (Author: ptupitsyn):
Benchmarks added: {{ThinClientGetBenchmark}}, {{ThinClientPutBenchmark}}

Results (op/s):
{code}
Put: 66K
ThinPut:  13K

Get: 110K
ThinGet:  14K
{code}

Merged to master: {{9813c626b3ac49e99d8b404aec44992e48dd1fed}}.

> .NET: Thin client: Cache benchmark
> --
>
> Key: IGNITE-7124
> URL: https://issues.apache.org/jira/browse/IGNITE-7124
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add a benchmark to see how thin client compares to full mode, see existing 
> {{PutBenchmark}} as an example.



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

[jira] [Assigned] (IGNITE-6976) Visor CMD: Add ability to put/get/remove data to caches via command line Visor.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6976:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Please test.

> Visor CMD: Add ability to put/get/remove data to caches via command line 
> Visor.
> ---
>
> Key: IGNITE-6976
> URL: https://issues.apache.org/jira/browse/IGNITE-6976
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>




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

[jira] [Updated] (IGNITE-7114) CPP: C++ node can't start without java examples folder

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-7114:

Summary: CPP: C++ node can't start without java examples folder  (was: C++ 
node can't start without java examples folder)

> CPP: C++ node can't start without java examples folder
> --
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Assigned] (IGNITE-6897) Visor doesn't show the list of caches after persistence enabled cluster restart

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6897:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master

> Visor doesn't show the list of caches after persistence enabled cluster 
> restart
> ---
>
> Key: IGNITE-6897
> URL: https://issues.apache.org/jira/browse/IGNITE-6897
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, visor
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> # Start a cluster with persistence enabled.
> # Create a cache dynamically, put some data.
> # Restart the cluster.
> # Connect with Visor and execute {{cache}} command to get list of caches.
> # No caches are shown.
> # Try to access the cache from code (e.g. execute a query).
> # Now caches are shown in Visor.



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

[jira] [Updated] (IGNITE-7128) .NET: Add missing DataRegionMetrics

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7128:
---
Description: See {{DataRegionMetricsParityTest}}.  (was: See 
{{ClusterMetricsParityTest}}.)

> .NET: Add missing DataRegionMetrics
> ---
>
> Key: IGNITE-7128
> URL: https://issues.apache.org/jira/browse/IGNITE-7128
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> See {{DataRegionMetricsParityTest}}.



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

[jira] [Commented] (IGNITE-7088) Wrong implementation of DIRECT comparator for ordering cache start operations

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev commented on IGNITE-7088:
---

Folks, please review my fix. TC looks good: 
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F3136%2Fhead

> Wrong implementation of DIRECT comparator for ordering cache start operations
> -
>
> Key: IGNITE-7088
> URL: https://issues.apache.org/jira/browse/IGNITE-7088
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.4
>
>
> {code:java}
> java.lang.IllegalArgumentException: Comparison method violates its general 
> contract!
>   at java.util.TimSort.mergeHi(TimSort.java:899) ~[?:1.8.0_102]
>   at java.util.TimSort.mergeAt(TimSort.java:516) ~[?:1.8.0_102]
>   at java.util.TimSort.mergeForceCollapse(TimSort.java:457) ~[?:1.8.0_102]
>   at java.util.TimSort.sort(TimSort.java:254) ~[?:1.8.0_102]
>   at java.util.Arrays.sort(Arrays.java:1512) ~[?:1.8.0_102]
>   at java.util.ArrayList.sort(ArrayList.java:1454) ~[?:1.8.0_102]
>   at java.util.Collections.sort(Collections.java:175) ~[?:1.8.0_102]
>   at 
> org.apache.ignite.internal.processors.cache.ClusterCachesInfo.orderedCaches(ClusterCachesInfo.java:1616)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.ClusterCachesInfo.cachesReceivedFromJoin(ClusterCachesInfo.java:839)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1709)
>  ~[ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:606)
>  [ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2278)
>  [ignite-core-2.1.7.jar:2.1.7]
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> [ignite-core-2.1.7.jar:2.1.7]
>   at java.lang.Thread.run(Thread.java:745) [?:1.8.0_102]
> {code}
> When 2 not user caches will be compared using this comparator, this above 
> exception will be thrown.
> As a workaround can be used system variable 
> -Djava.util.Arrays.useLegacyMergeSort=true 



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

[jira] [Resolved] (IGNITE-7123) .NET: Verify metrics API parity with a test

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7123.

Resolution: Fixed

> .NET: Verify metrics API parity with a test
> ---
>
> Key: IGNITE-7123
> URL: https://issues.apache.org/jira/browse/IGNITE-7123
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Similar to IGNITE-6264 add tests for all metrics interfaces.



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

[jira] [Commented] (IGNITE-7123) .NET: Verify metrics API parity with a test

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7123:


Merged to master: {{4717570cfc6263ca3beb2ef6df53f5edef365fdc}}.

> .NET: Verify metrics API parity with a test
> ---
>
> Key: IGNITE-7123
> URL: https://issues.apache.org/jira/browse/IGNITE-7123
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Similar to IGNITE-6264 add tests for all metrics interfaces.



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

[jira] [Created] (IGNITE-7128) .NET: Add missing DataRegionMetrics

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7128:
--

 Summary: .NET: Add missing DataRegionMetrics
 Key: IGNITE-7128
 URL: https://issues.apache.org/jira/browse/IGNITE-7128
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Priority: Minor


See {{ClusterMetricsParityTest}}.



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

[jira] [Comment Edited] (IGNITE-7123) .NET: Verify metrics API parity with a test

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7123 at 12/6/17 4:39 PM:
-

Tickets created: IGNITE-7126, IGNITE-7127, IGNITE-7128


was (Author: ptupitsyn):
Tickets created: IGNITE-7126, IGNITE-7127

> .NET: Verify metrics API parity with a test
> ---
>
> Key: IGNITE-7123
> URL: https://issues.apache.org/jira/browse/IGNITE-7123
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Similar to IGNITE-6264 add tests for all metrics interfaces.



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

[jira] [Updated] (IGNITE-7127) .NET: Add missing ClusterMetrics

[Pavel Tupitsyn (JIRA)]

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

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

> .NET: Add missing ClusterMetrics
> 
>
> Key: IGNITE-7127
> URL: https://issues.apache.org/jira/browse/IGNITE-7127
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> See {{ClusterMetricsParityTest}}.



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

[jira] [Updated] (IGNITE-7126) .NET: Add missing CacheMetrics

[Pavel Tupitsyn (JIRA)]

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

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

> .NET: Add missing CacheMetrics
> --
>
> Key: IGNITE-7126
> URL: https://issues.apache.org/jira/browse/IGNITE-7126
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> See {{CacheMetricsParityTest}} for a list of missing metrics.



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

[jira] [Commented] (IGNITE-7080) YARN fails to create containers if Bash functions exported in environment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7080:


Github user asfgit closed the pull request at:

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


> YARN fails to create containers if Bash functions exported in environment
> -
>
> Key: IGNITE-7080
> URL: https://issues.apache.org/jira/browse/IGNITE-7080
> Project: Ignite
>  Issue Type: Bug
>  Components: yarn
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Attachments: ignite-7080.patch
>
>
> Ignite YARN collects all existing environment variables to pass them to 
> container, including variables with incorrect names, such as Bash functions, 
> which have extra characters at the end, and are ignored by most shells but 
> not the JVM.
> When you tell Bash to export functions, it puts 
> BASH_FUNC_your_function_name%% variable into env. This is what is causing 
> problems because Ignite YARN picks this variable and tells Hadoop to pass it 
> to container, which leads to incorrectly written startup scrips.
> Hadoop tries to sanitize env var values but not env var names. I think Ignite 
> should not try to pass all env vars to containers (it may contain sensitive 
> or master-specific vars!). We should only pass env vars that are relevant to 
> containers, such as IGNITE_* vars.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/Error-running-ignite-in-YARN-td18280.html



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

[jira] [Comment Edited] (IGNITE-7097) performance measurement for SparseDistributedMatrix multiplication

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko edited comment on IGNITE-7097 at 12/6/17 4:31 PM:
-

I experimented with running benchmarks using ML codebase in master: the issue 
is still reproducible. Whatever causes it, apparently hasn't been fixed yet. 
Plan to check if maybe there is some kind of leak, maybe intermediate objects 
are created by {{likeMatrix}} or {{likeVector}} (possibly eg through {{copy}}) 
somewhere within multiplication without corresponding {{destroy}} because in 
past experiments it was missing destroy that caused yardstick to hang


was (Author: oignatenko):
I experimented with running benchmarks using ML codebase in master: the issue 
is still reproducible. Whatever causes it, apparently hasn't been fixed yet. 
Plan to check if maybe there is some kind of leak, maybe intermediate objects 
are created by {{likeMatrix}} or {{likeVector}} somewhere within multiplication 
without corresponding {{destroy}} because in past experiments it was missing 
destroy that caused yardstick to hang

> performance measurement for SparseDistributedMatrix multiplication
> --
>
> Key: IGNITE-7097
> URL: https://issues.apache.org/jira/browse/IGNITE-7097
> Project: Ignite
>  Issue Type: Task
>  Components: ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> We want to start tracking our performance to avoid performance degradation. 
> Also we need some performance comparison with other ml libs.
> Initial draft for this benchmark was made per IGNITE-6123 (class 
> {{IgniteSparseDistributedMatrixMulBenchmark}}) but it currently hangs so it 
> is excluded. Find a way to do it right.



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

[jira] [Commented] (IGNITE-7097) performance measurement for SparseDistributedMatrix multiplication

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-7097:


I experimented with running benchmarks using ML codebase in master: the issue 
is still reproducible. Whatever causes it, apparently hasn't been fixed yet. 
Plan to check if maybe there is some kind of leak, maybe intermediate objects 
are created by {{likeMatrix}} or {{likeVector}} somewhere within multiplication 
without corresponding {{destroy}} because in past experiments it was missing 
destroy that caused yardstick to hang

> performance measurement for SparseDistributedMatrix multiplication
> --
>
> Key: IGNITE-7097
> URL: https://issues.apache.org/jira/browse/IGNITE-7097
> Project: Ignite
>  Issue Type: Task
>  Components: ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> We want to start tracking our performance to avoid performance degradation. 
> Also we need some performance comparison with other ml libs.
> Initial draft for this benchmark was made per IGNITE-6123 (class 
> {{IgniteSparseDistributedMatrixMulBenchmark}}) but it currently hangs so it 
> is excluded. Find a way to do it right.



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

[jira] [Comment Edited] (IGNITE-7123) .NET: Verify metrics API parity with a test

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7123 at 12/6/17 4:23 PM:
-

Tickets created: IGNITE-7126, IGNITE-7127


was (Author: ptupitsyn):
Tickets created: IGNITE-7126

> .NET: Verify metrics API parity with a test
> ---
>
> Key: IGNITE-7123
> URL: https://issues.apache.org/jira/browse/IGNITE-7123
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Similar to IGNITE-6264 add tests for all metrics interfaces.



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

[jira] [Created] (IGNITE-7127) .NET: Add missing ClusterMetrics

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7127:
--

 Summary: .NET: Add missing ClusterMetrics
 Key: IGNITE-7127
 URL: https://issues.apache.org/jira/browse/IGNITE-7127
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn


See {{ClusterMetricsParityTest}}.



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

[jira] [Commented] (IGNITE-7080) YARN fails to create containers if Bash functions exported in environment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7080:


GitHub user alamar opened a pull request:

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

IGNITE-7080 Check env variable names to only pass IGNITE_* to nodes.



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

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

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

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


commit b3ececfd8a226da577fe2390142ac4ebc25b6e07
Author: Ilya Kasnacheev 
Date:   2017-12-06T16:20:35Z

IGNITE-7080 Check env variable names to only pass IGNITE_* to nodes.




> YARN fails to create containers if Bash functions exported in environment
> -
>
> Key: IGNITE-7080
> URL: https://issues.apache.org/jira/browse/IGNITE-7080
> Project: Ignite
>  Issue Type: Bug
>  Components: yarn
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Attachments: ignite-7080.patch
>
>
> Ignite YARN collects all existing environment variables to pass them to 
> container, including variables with incorrect names, such as Bash functions, 
> which have extra characters at the end, and are ignored by most shells but 
> not the JVM.
> When you tell Bash to export functions, it puts 
> BASH_FUNC_your_function_name%% variable into env. This is what is causing 
> problems because Ignite YARN picks this variable and tells Hadoop to pass it 
> to container, which leads to incorrectly written startup scrips.
> Hadoop tries to sanitize env var values but not env var names. I think Ignite 
> should not try to pass all env vars to containers (it may contain sensitive 
> or master-specific vars!). We should only pass env vars that are relevant to 
> containers, such as IGNITE_* vars.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/Error-running-ignite-in-YARN-td18280.html



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

[jira] [Created] (IGNITE-7126) .NET: Add missing CacheMetrics

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7126:
--

 Summary: .NET: Add missing CacheMetrics
 Key: IGNITE-7126
 URL: https://issues.apache.org/jira/browse/IGNITE-7126
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn


See {{CacheMetricsParityTest}} for a list of missing metrics.



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

[jira] [Commented] (IGNITE-7123) .NET: Verify metrics API parity with a test

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7123:


Tickets created: IGNITE-7126

> .NET: Verify metrics API parity with a test
> ---
>
> Key: IGNITE-7123
> URL: https://issues.apache.org/jira/browse/IGNITE-7123
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Similar to IGNITE-6264 add tests for all metrics interfaces.



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

[jira] [Assigned] (IGNITE-6987) Visor CMD: Config command should show client connector pool size.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6987:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master.

> Visor CMD: Config command should show client connector pool size.
> -
>
> Key: IGNITE-6987
> URL: https://issues.apache.org/jira/browse/IGNITE-6987
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Now show size for deprecated SqlConnectorConfiguration.



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

[jira] [Created] (IGNITE-7125) Cluster metrics for a single node differ from local metrics

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-7125:


 Summary: Cluster metrics for a single node differ from local 
metrics
 Key: IGNITE-7125
 URL: https://issues.apache.org/jira/browse/IGNITE-7125
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Denis Mekhanikov


Some metrics, that perform aggregation of multiple values, have different 
meanings for a local node and for a cluster. Local metrics perform aggregation 
over time, but cluster metrics – over nodes in the cluster. As a result, you 
can get different values of local metrics and cluster metrics, when there is 
only one node in the cluster.

Here is a reproducer:
{code}
public class ExampleNodeStartup {
public static void main(String[] args) throws Exception {
Ignite ignite = Ignition.start();

while (true) {
ClusterMetrics locMetrics = ignite.cluster().localNode().metrics();
ClusterMetrics clusterMetrics = ignite.cluster().metrics();

System.out.println("averageCpuLoad: " +
"local=" + locMetrics.getAverageCpuLoad() +
"; cluster=" + clusterMetrics.getAverageCpuLoad());
System.out.println("maximumThreadCount: " +
"local=" + locMetrics.getMaximumThreadCount() +
"; cluster=" + clusterMetrics.getMaximumThreadCount());

Thread.sleep(200);
}
}
}
{code}

After some time values begin to differ.

All {{ClusterMetrics#getMaximum*}} and {{ClusterMetrics#getAverage*}} metrics 
seem to have the same problem.



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

[jira] [Commented] (IGNITE-6868) Implement new JMX metrics for TcpCommunicationSpi monitoring

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov commented on IGNITE-6868:
---

[~vozerov],
I returned methods, make methods used in MBean implementation (as it was for 
metrics like {{getReceivedBytesCount}}), so they are covered by unit tests now.
Please review again.

> Implement new JMX metrics for TcpCommunicationSpi monitoring
> 
>
> Key: IGNITE-6868
> URL: https://issues.apache.org/jira/browse/IGNITE-6868
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented in TcpCommunicationSpi MBean:
> * Received messages count grouped by message type
> * Received messages count grouped by sender node
> * Sent messages count grouped by message type
> * Sent messages count grouped by receiver node



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

[jira] [Commented] (IGNITE-7114) C++ node can't start without java examples folder

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7114:


GitHub user isapego opened a pull request:

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

IGNITE-7114: C++ node can now start without java examples folder.



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

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

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

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


commit db1136828b11647226c73d38ff2586e52cfc9b3b
Author: Igor Sapego 
Date:   2017-12-06T13:51:16Z

IGNITE-7114: Fixed for Windows

commit eb515c99aa3964b0c06c16418ad12bf30f91a73e
Author: Igor Sapego 
Date:   2017-12-06T14:16:29Z

IGNITE-7114: Fixed for Linux.

commit 16f8bd860d9d688d840112eac9f5e70a88be2941
Author: Igor Sapego 
Date:   2017-12-06T15:00:07Z

IGNITE-7114: Fixes for Linux

commit 6d9143fecdb275f5f8b25ab3bb467f027464ecbe
Author: Igor Sapego 
Date:   2017-12-06T15:08:12Z

IGNITE-7114: Minor fix




> C++ node can't start without java examples folder
> -
>
> Key: IGNITE-7114
> URL: https://issues.apache.org/jira/browse/IGNITE-7114
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.4
>
>
> Error message: 
> ERROR: Java classpath is empty (did you set {{IGNITE_HOME}} environment 
> variable?)



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

[jira] [Assigned] (IGNITE-4835) Add ability to start rebalancing from management console

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4835:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Please test

> Add ability to start rebalancing from management console
> 
>
> Key: IGNITE-4835
> URL: https://issues.apache.org/jira/browse/IGNITE-4835
> Project: Ignite
>  Issue Type: New Feature
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
>Priority: Minor
>
> Management console should allow for starting rebalancing manually.



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

[jira] [Updated] (IGNITE-7123) .NET: Verify metrics API parity with a test

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7123:
---
Summary: .NET: Verify metrics API parity with a test  (was: IGNITE-6264 
.NET: Verify metrics API parity with a test)

> .NET: Verify metrics API parity with a test
> ---
>
> Key: IGNITE-7123
> URL: https://issues.apache.org/jira/browse/IGNITE-7123
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Similar to IGNITE-6264 add tests for all metrics interfaces.



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

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 12/6/17 2:45 PM:
---

[~vkulichenko] Only primary and backups.

I have 2 questions left, could you please answer them: 


11) getEntryProcessorHits() - Hit number - number of total entry processor 
invocations happened on keys exsisting in cache. While Mises number - number of 
invocations on keys not existing in cache. Am i right ?


12) Don't you mind if i create a separate ticket(current ticket sub-task) for 
the following metrics(motivation below) ?
{code:java}
getMinEntryProcessorReadOnlyInvocationTime();
getAverageEntryProcessorReadOnlyInvocationTime();
getMaxEntryProcessorReadOnlyInvocationTime();
{code}

_Motivation :_ too much new complicated code needed.

_How time calculations work_ : we start invoke by sending certain request to 
primary node and waiting for response.When response is received we must 
calculate time.

_Problem, faced when implementing 'read-only invoke time' metrics:_ response 
message contains no information about whether it was 'read-only' or 
'update'\'remove' operation. As a result we cannot decide whether we should 
increment 'read-only' or 'update'\'remove' metric.

_Solution to problem:_ alter message, add field indicating transform operation 
was performed.


was (Author: alexey kuznetsov):
[~vkulichenko] Only primary and backups.

I have 2 questions left, could you please answer them: 


11) getEntryProcessorHits() - Hit number - number of total entry processor 
invocations happened on keys exsisting in cache. While Mises number - number of 
invocations on keys not existing in cache. Am i right ?


12) Don't you mind if i create a separate ticket for the following 
metrics(motivation below) ?
{code:java}
getMinEntryProcessorReadOnlyInvocationTime();
getAverageEntryProcessorReadOnlyInvocationTime();
getMaxEntryProcessorReadOnlyInvocationTime();
{code}

_Motivation :_ too much new complicated code needed.

_How time calculations work_ : we start invoke by sending certain request to 
primary node and waiting for response.When response is received we must 
calculate time.

_Problem, faced when implementing 'read-only invoke time' metrics:_ response 
message contains no information about whether it was 'read-only' or 
'update'\'remove' operation. As a result we cannot decide whether we should 
increment 'read-only' or 'update'\'remove' metric.

_Solution to problem:_ alter message, add field indicating transform operation 
was performed.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 12/6/17 2:44 PM:
---

[~vkulichenko] Only primary and backups.

I have 2 questions left, could you please answer them: 


11) getEntryProcessorHits() - Hit number - number of total entry processor 
invocations happened on keys exsisting in cache. While Mises number - number of 
invocations on keys not existing in cache. Am i right ?


12) Don't you mind if i create a separate ticket for the following 
metrics(motivation below) ?
{code:java}
getMinEntryProcessorReadOnlyInvocationTime();
getAverageEntryProcessorReadOnlyInvocationTime();
getMaxEntryProcessorReadOnlyInvocationTime();
{code}

_Motivation :_ too much new complicated code needed.

_How time calculations work_ : we start invoke by sending certain request to 
primary node and waiting for response.When response is received we must 
calculate time.

_Problem, faced when implementing 'read-only invoke time' metrics:_ response 
message contains no information about whether it was 'read-only' or 
'update'\'remove' operation. As a result we cannot decide whether we should 
increment 'read-only' or 'update'\'remove' metric.

_Solution to problem:_ alter message, add field indicating transform operation 
was performed.


was (Author: alexey kuznetsov):
[~vkulichenko] Only primary and backups.

I have 2 questions left, could you please answer them: 

11) getEntryProcessorHits() - Hit number - number of total entry processor 
invocations happened on keys exsisting in cache. While Mises number - number of 
invocations on keys not existing in cache. Am i right ?

12) Don't you mind if i create a separate ticket for the following 
metrics(motivation below) ?
{code:java}
getMinEntryProcessorReadOnlyInvocationTime();
getAverageEntryProcessorReadOnlyInvocationTime();
getMaxEntryProcessorReadOnlyInvocationTime();
{code}

_Motivation :_ too much new complicated code needed.

_How time calculations work_ : we start invoke by sending certain request to 
primary node and waiting for response.When response is received we must 
calculate time.

_Problem, faced when implementing 'read-only invoke time' metrics:_ response 
message contains no information about whether it was 'read-only' or 
'update'\'remove' operation. As a result we cannot decide whether we should 
increment 'read-only' or 'update'\'remove' metric.

_Solution to problem:_ alter message, add field indicating transform operation 
was performed.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 12/6/17 2:44 PM:
---

[~vkulichenko] Only primary and backups.

I have 2 questions left, could you please answer them: 

11) getEntryProcessorHits() - Hit number - number of total entry processor 
invocations happened on keys exsisting in cache. While Mises number - number of 
invocations on keys not existing in cache. Am i right ?

12) Don't you mind if i create a separate ticket for the following 
metrics(motivation below) ?
{code:java}
getMinEntryProcessorReadOnlyInvocationTime();
getAverageEntryProcessorReadOnlyInvocationTime();
getMaxEntryProcessorReadOnlyInvocationTime();
{code}

_Motivation :_ too much new complicated code needed.

_How time calculations work_ : we start invoke by sending certain request to 
primary node and waiting for response.When response is received we must 
calculate time.

_Problem, faced when implementing 'read-only invoke time' metrics:_ response 
message contains no information about whether it was 'read-only' or 
'update'\'remove' operation. As a result we cannot decide whether we should 
increment 'read-only' or 'update'\'remove' metric.

_Solution to problem:_ alter message, add field indicating transform operation 
was performed.


was (Author: alexey kuznetsov):
[~vkulichenko] Only primary and backups

I have 2 questions left, could you please answer them: 

11) getEntryProcessorHits() - Hit number - number of total entry processor 
invocations happened on keys exsisting in cache. While Mises number - number of 
invocations on keys not existing in cache. Am i right ?

12) Don't you mind if i create a separate ticket for the following 
metrics(motivation below) ?
{code:java}
getMinEntryProcessorReadOnlyInvocationTime();
getAverageEntryProcessorReadOnlyInvocationTime();
getMaxEntryProcessorReadOnlyInvocationTime();
{code}

_Motivation :_ too much new complicated code needed.

_How time calculations work_ : we start invoke by sending certain request to 
primary node and waiting for response.When response is received we must 
calculate time.

_Problem, faced when implementing 'read-only invoke time' metrics:_ response 
message contains no information about whether it was 'read-only' or 
'update'\'remove' operation. As a result we cannot decide whether we should 
increment 'read-only' or 'update'\'remove' metric.

_Solution to problem:_ alter message, add field indicating transform operation 
was performed.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Commented] (IGNITE-7109) .NET: Thin client: Async cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7109:


Let's implement IGNITE-7124 first so that we can compare performance.

> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Created] (IGNITE-7124) .NET: Thin client: Cache benchmark

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7124:
--

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


Add a benchmark to see how thin client compares to full mode, see existing 
{{PutBenchmark}} as an example.



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

[jira] [Commented] (IGNITE-6871) Implement new JMX metrics for partitions map monitoring

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov commented on IGNITE-6871:
---

[~vozerov] fixed

> Implement new JMX metrics for partitions map monitoring
> ---
>
> Key: IGNITE-6871
> URL: https://issues.apache.org/jira/browse/IGNITE-6871
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented to monitor partitions map per 
> each cache group:
> * Total primary partitions count located on the current node
> * Total backup partitions count located on the current node
> * Min/max partition backups left in the cluster for cache group
> * Maybe some methods to show partitions map/partition distribution statistics 
> in the cluster



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

[jira] [Assigned] (IGNITE-4750) SQL: Support GROUP_CONCAT function

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-4750:


Assignee: Taras Ledkov

> SQL: Support GROUP_CONCAT function
> --
>
> Key: IGNITE-4750
> URL: https://issues.apache.org/jira/browse/IGNITE-4750
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>
> GROUP_CONCAT function is not supported at the moment. Makes sense to fill 
> this gap:
> http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html



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

[jira] [Resolved] (IGNITE-5575) Ignite returns wrong CacheMetrics for cluster group

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov resolved IGNITE-5575.
--
Resolution: Duplicate

> Ignite returns wrong CacheMetrics for cluster group
> ---
>
> Key: IGNITE-5575
> URL: https://issues.apache.org/jira/browse/IGNITE-5575
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
> Attachments: MultiNodeMetricsTest.java, ignite-cfg.xml, 
> ignite-cfg2.xml
>
>
> CacheMetrics metrics = 
> cache.metrics(cluster.forCacheNodes(DEFAULT_CACHE_NAME)); returns cache 
> metrics only for the local node.
> Looks like cache metrics exchange is broken.



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

[jira] [Commented] (IGNITE-5575) Ignite returns wrong CacheMetrics for cluster group

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov commented on IGNITE-5575:
--

This is actually a problem of CacheMetrics#getSize() and 
CacheMetrics#getKeySize().
Here is the ticket: IGNITE-6564

> Ignite returns wrong CacheMetrics for cluster group
> ---
>
> Key: IGNITE-5575
> URL: https://issues.apache.org/jira/browse/IGNITE-5575
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
> Attachments: MultiNodeMetricsTest.java, ignite-cfg.xml, 
> ignite-cfg2.xml
>
>
> CacheMetrics metrics = 
> cache.metrics(cluster.forCacheNodes(DEFAULT_CACHE_NAME)); returns cache 
> metrics only for the local node.
> Looks like cache metrics exchange is broken.



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

[jira] [Commented] (IGNITE-6971) Ignite Logger type & logging file config indication

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6971:


Github user asfgit closed the pull request at:

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


> Ignite Logger type & logging file config indication
> ---
>
> Key: IGNITE-6971
> URL: https://issues.apache.org/jira/browse/IGNITE-6971
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
> Fix For: 2.4
>
>
> Please see 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Logger-amp-logging-file-config-output-td24435.html



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

[jira] [Commented] (IGNITE-7120) Test cases inherited by AbstractSchemaSelfTest became flucky after the refactoring to use SQL API.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7120:


Github user asfgit closed the pull request at:

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


> Test cases inherited by AbstractSchemaSelfTest became flucky after the 
> refactoring to use SQL API.
> --
>
> Key: IGNITE-7120
> URL: https://issues.apache.org/jira/browse/IGNITE-7120
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Assignee: Alexander Paschenko
> Fix For: 2.4
>
>
> This problem may be caused by the delay between CREATE INDEX command and the 
> consequitive JDBC metadata updating.  Therefore, a metadata info may be 
> outdated in AbstractSchemaSelfTest#assertIndex() {.. 
> c.getMetaData().getIndexInfo() ..}



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

[jira] [Commented] (IGNITE-7086) Backups are not updated when ReadFromBackup=true and ReadThrough happens.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7086:


GitHub user dkarachentsev opened a pull request:

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

IGNITE-7086 - Backups are not updated when ReadFromBackup=true and Re…

…adThrough happens.

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

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

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

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


commit 161892eee237a197d93f29c4e332fe1b0a7c9397
Author: dkarachentsev 
Date:   2017-12-06T13:06:11Z

IGNITE-7086 - Backups are not updated when ReadFromBackup=true and 
ReadThrough happens.




> Backups are not updated when ReadFromBackup=true and ReadThrough happens.
> -
>
> Key: IGNITE-7086
> URL: https://issues.apache.org/jira/browse/IGNITE-7086
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Dmitry Karachentsev
> Fix For: 2.4
>
> Attachments: ReplicatedReadFromBackupWithStoreTest.java
>
>
> Ignite Replicated cache with CacheStore and ReadThrough=true and 
> ReadFromBackup=true works in unexpected way from user perspective.
> On backup node, get operation will always go to the primary node regardless 
> of ReadFromBackup=true and ReadThrough=true when entry doesn't exists in 
> local map.
> So, Replicated cache works like a Partitioned with no backups.



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

[jira] [Created] (IGNITE-7123) IGNITE-6264 .NET: Verify metrics API parity with a test

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7123:
--

 Summary: IGNITE-6264 .NET: Verify metrics API parity with a test
 Key: IGNITE-7123
 URL: https://issues.apache.org/jira/browse/IGNITE-7123
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.4


Similar to IGNITE-6264 add tests for all metrics interfaces.



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

[jira] [Commented] (IGNITE-7122) Page lock status is not checked in BPlusTree.treePrinter methods

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7122:


GitHub user gg-shq opened a pull request:

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

IGNITE-7122: Fixed assertion in BPLusTree printing code



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

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

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

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


commit 9af2f53973302cc9b39d0707ff8d90fb8dd45008
Author: gg-shq 
Date:   2017-12-06T12:14:53Z

IGNITE-7122: Fixed assertion BPLusTree printing code




> Page lock status is not checked in BPlusTree.treePrinter methods
> 
>
> Key: IGNITE-7122
> URL: https://issues.apache.org/jira/browse/IGNITE-7122
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
>
> The result of readLock(), which can be 0 is not checked in 
> BPlusTree.treePrinter getChildren() and formatTreeNode() calls:
> {noformat}
> java.lang.AssertionError: 0
> at 
> org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.getPageId(PageIO.java:279)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.checkPageId(BPlusTreeSelfTest.java:2307)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$TestTree.onReadUnlock(BPlusTreeSelfTest.java:2445)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readUnlock(PageHandler.java:203)
> at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.readUnlock(DataStructure.java:186)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$400(BPlusTree.java:82)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:163)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:120)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:60)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:67)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:32)
> at 
> org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:43)
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.printTree(BPlusTree.java:1188)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1777)
> at 
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1771)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> ...which causes intermittent failures in the BPlusTree unit tests:
> BPlusTreePageMemoryImplTest.testPutRmvSizeSinglePageContention
> BPlusTreeReuseListPageMemoryImplTest.testPutRmvSizeSinglePageContention 



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

[jira] [Comment Edited] (IGNITE-6983) SQL: optimize CREATE INDEX and BPlusTree interaction

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-6983 at 12/6/17 12:11 PM:


The result of the simple simple benchmark of the index creation.
Host: 2x Xeon X5570 96Gb 512GB SSD 2048GB HDD 
Ignite configuration: storage is enabled, but checkpoint frequency is 
{{Long.MAX_VALUE}}, and data region is 60G (so checkpoint doesn't happen for 
the benchmark run).

|| Seconds of index creation master / patch  ||  parallel 1 || parallel  4 || 
parallel 8 ||
| Keys *5M* | 185 / 193 {color:red}-4%{color}  | 65 / 61 
{color:green}+6%{color} | 51 / 40 {color:green}+27%{color}|
| Keys *10M* | 373 / 375 0% | 129 / 123 +4% 
  | 103 / 81 {color:green}+27%{color} |
| Keys *20M* | 758 / 793 {color:red}-4%{color} | 285 / 277 +2%  
 | 220 / 172 {color:green}+28%{color} |
| Keys *50M* | 2117 / 2202 {color:red}-3%{color} | 728 / 671 
{color:green}+8%{color} | 585 / 437 {color:green}+33%{color} |


was (Author: tledkov-gridgain):
The result of the simple simple benchmark of the index creation.
Host: 2x Xeon X5570 96Gb 512GB SSD 2048GB HDD 
Ignite configuration: storage is enabled, but checkpoint frequency is 
{{Long.MAX_VALUE}}, and data region is 60G (so checkpoint doesn't happen for 
the benchmark run).

|| Seconds of index creation master / patch  ||  parallel 1 || parallel  4 || 
parallel 8 ||
| Keys *5M* | 185 / 193 {color:red}-4%{color}  | 65 / 61 
{color:green}+6%{color} | 51 / 40 {color:green}+27%{color}|
| Keys *10M* | 373 / 375 0% | 129 / 123 +4% 
  | 103 / 81 {color:green}+27%{color} |
| Keys *20M* | 758 / 793 {color:red}-4%{color} | 285 / 277 +2%  
 | 220 / 172 {color:green}+28%{color} |
| Keys *50M* | 2117 / 2202 {color:red}-3%{color} | 728 / 671 
{color:green}+8%{color} | -- |

> SQL: optimize CREATE INDEX and BPlusTree interaction
> 
>
> Key: IGNITE-6983
> URL: https://issues.apache.org/jira/browse/IGNITE-6983
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>  Labels: iep-1
> Fix For: 2.4
>
>
> Currently index is built as follows:
> 1) Get next entry from partition's tree
> 2) Read it's key (copy to heap)
> 3) Acquire lock on {{GridCacheMapEntry}}
> 4) Lookup the same key in the tree from the top
> 5) Read it's value (copy to heap)
> 6) Add to index.
> This is very complex flow. We can optimize two things - tree lookup and value 
> deserialization as follows:
> 1) Every data page will have update counter, which is incremented every time 
> anything is changed.
> 2) When lock on {{GridCacheMapEntry}} is acquired, we will acquire lock on 
> the data page and re-check update counter. 
> 3) If page was changed between iterator read and lock acquisition then use 
> old flow. 
> 4) Otherwise - set read lock on the page, read value as *offheap* object, 
> apply it to index.



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

[jira] [Updated] (IGNITE-7122) Page lock status is not checked in BPlusTree.treePrinter methods

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov updated IGNITE-7122:

Description: 
The result of readLock(), which can be 0 is not checked in 
BPlusTree.treePrinter getChildren() and formatTreeNode() calls:

{noformat}
java.lang.AssertionError: 0
at org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.getPageId(PageIO.java:279)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.checkPageId(BPlusTreeSelfTest.java:2307)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$TestTree.onReadUnlock(BPlusTreeSelfTest.java:2445)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readUnlock(PageHandler.java:203)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.readUnlock(DataStructure.java:186)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$400(BPlusTree.java:82)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:163)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:120)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:60)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:67)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:32)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:43)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.printTree(BPlusTree.java:1188)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1777)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1771)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{noformat}

...which causes intermittent failures in the BPlusTree unit tests:

BPlusTreePageMemoryImplTest.testPutRmvSizeSinglePageContention  
BPlusTreeReuseListPageMemoryImplTest.testPutRmvSizeSinglePageContention 

  was:
The result of readLock(), which can be 0 is not checked in 
BPlusTree.treePrinter getChildren() and formatTreeNode() calls:

java.lang.AssertionError: 0
at org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.getPageId(PageIO.java:279)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.checkPageId(BPlusTreeSelfTest.java:2307)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$TestTree.onReadUnlock(BPlusTreeSelfTest.java:2445)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readUnlock(PageHandler.java:203)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.readUnlock(DataStructure.java:186)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$400(BPlusTree.java:82)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:163)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:120)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:60)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:67)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:32)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:43)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.printTree(BPlusTree.java:1188)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1777)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1771)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)

...which causes intermittent failures in the BPlusTree unit tests:

BPlusTreePageMemoryImplTest.testPutRmvSizeSinglePageContention  
BPlusTreeReuseListPageMemoryImplTest.testPutRmvSizeSinglePageContention 


> Page lock status is not checked in BPlusTree.treePrinter methods
> 
>
> Key: IGNITE-7122
> URL: https://issues.apache.org/jira/browse/IGNITE-7122
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
>
> The result 

[jira] [Updated] (IGNITE-7122) Page lock status is not checked in BPlusTree.treePrinter methods

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov updated IGNITE-7122:

Description: 
The result of readLock(), which can be 0 is not checked in 
BPlusTree.treePrinter getChildren() and formatTreeNode() calls:

java.lang.AssertionError: 0
at org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.getPageId(PageIO.java:279)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.checkPageId(BPlusTreeSelfTest.java:2307)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$TestTree.onReadUnlock(BPlusTreeSelfTest.java:2445)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readUnlock(PageHandler.java:203)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.readUnlock(DataStructure.java:186)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$400(BPlusTree.java:82)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:163)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:120)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:60)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:67)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:32)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:43)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.printTree(BPlusTree.java:1188)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1777)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1771)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)

...which causes intermittent failures in the BPlusTree unit tests:

BPlusTreePageMemoryImplTest.testPutRmvSizeSinglePageContention  
BPlusTreeReuseListPageMemoryImplTest.testPutRmvSizeSinglePageContention 

  was:
The result of readLock(), which can be 0 is not checked in 
BPlusTree.treePrinter getChildren() and formatTreeNode() calls:

java.lang.AssertionError: 0
at org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.getPageId(PageIO.java:279)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.checkPageId(BPlusTreeSelfTest.java:2307)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$TestTree.onReadUnlock(BPlusTreeSelfTest.java:2445)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readUnlock(PageHandler.java:203)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.readUnlock(DataStructure.java:186)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$400(BPlusTree.java:82)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:163)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:120)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:60)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:67)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:32)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:43)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.printTree(BPlusTree.java:1188)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1777)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1771)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)


> Page lock status is not checked in BPlusTree.treePrinter methods
> 
>
> Key: IGNITE-7122
> URL: https://issues.apache.org/jira/browse/IGNITE-7122
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
>
> The result of readLock(), which can be 0 is not checked in 
> BPlusTree.treePrinter getChildren() and formatTreeNode() calls:
> java.lang.AssertionError: 0
> at 
> org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
> at 

[jira] [Created] (IGNITE-7122) Page lock status is not checked in BPlusTree.treePrinter methods

[Kirill Shirokov (JIRA)]

Kirill Shirokov created IGNITE-7122:
---

 Summary: Page lock status is not checked in BPlusTree.treePrinter 
methods
 Key: IGNITE-7122
 URL: https://issues.apache.org/jira/browse/IGNITE-7122
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.4
Reporter: Kirill Shirokov
Assignee: Kirill Shirokov


The result of readLock(), which can be 0 is not checked in 
BPlusTree.treePrinter getChildren() and formatTreeNode() calls:

java.lang.AssertionError: 0
at org.apache.ignite.internal.pagemem.PageUtils.getLong(PageUtils.java:117)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO.getPageId(PageIO.java:279)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.checkPageId(BPlusTreeSelfTest.java:2307)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$TestTree.onReadUnlock(BPlusTreeSelfTest.java:2445)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readUnlock(PageHandler.java:203)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.readUnlock(DataStructure.java:186)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$400(BPlusTree.java:82)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:163)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$1.getChildren(BPlusTree.java:120)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:60)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.printTree(GridTreePrinter.java:67)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:32)
at 
org.apache.ignite.internal.util.lang.GridTreePrinter.print(GridTreePrinter.java:43)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.printTree(BPlusTree.java:1188)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1777)
at 
org.apache.ignite.internal.processors.database.BPlusTreeSelfTest$19.call(BPlusTreeSelfTest.java:1771)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)



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

[jira] [Comment Edited] (IGNITE-6903) Implement new JMX metrics for Indexing

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-6903 at 12/6/17 11:06 AM:
---

PR - https://github.com/apache/ignite/pull/3135
Upsource - https://reviews.ignite.apache.org/ignite/review/IGNT-CR-420
Team city - https://ci.ignite.apache.org/viewQueued.html?itemId=979290


was (Author: nizhikov):
PR - https://github.com/apache/ignite/pull/3135
Upsource - https://reviews.ignite.apache.org/ignite/review/IGNT-CR-420
Team city - https://ci.ignite.apache.org/viewQueued.html?itemId=977300

> Implement new JMX metrics for Indexing
> --
>
> Key: IGNITE-6903
> URL: https://issues.apache.org/jira/browse/IGNITE-6903
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: iep-6, important
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> - Space occupied by indexes.



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

[jira] [Commented] (IGNITE-6871) Implement new JMX metrics for partitions map monitoring

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6871:
-

[~alex_pl], [~avinogradov],
I would rename the method to {{getGroupName}} and return only group name, 
meaning that it could be {{null}}. Otherwise we confuse user:
1) He cannot understand whether this is a cache name or group name
2) He may guess that this is a group name and try setting it into configuration 
of some new cache and get surprising results - new cache will not be in the 
same group as existing one.

> Implement new JMX metrics for partitions map monitoring
> ---
>
> Key: IGNITE-6871
> URL: https://issues.apache.org/jira/browse/IGNITE-6871
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented to monitor partitions map per 
> each cache group:
> * Total primary partitions count located on the current node
> * Total backup partitions count located on the current node
> * Min/max partition backups left in the cluster for cache group
> * Maybe some methods to show partitions map/partition distribution statistics 
> in the cluster



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

[jira] [Assigned] (IGNITE-6923) Cache metrics are updated in timeout-worker potentially delaying critical code execution due to current implementation issues.

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-6923:


Assignee: Aleksey Plekhanov

> Cache metrics are updated in timeout-worker potentially delaying critical 
> code execution due to current implementation issues.
> --
>
> Key: IGNITE-6923
> URL: https://issues.apache.org/jira/browse/IGNITE-6923
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6
> Fix For: 2.4
>
>
> Some metrics are using cache iteration for calculation. If number of caches 
> rather large this can be slow.
> Similar code is running in discovery thread.
> See stack trace for example.
> {noformat}
> "grid-timeout-worker-#39%DPL_GRID%DplGridNodeName%" #152 prio=5 os_prio=0 
> tid=0x7f1009a03000 nid=0x5caa runnable [0x7f0f059d9000] 
>java.lang.Thread.State: RUNNABLE 
> at java.util.HashMap.containsKey(HashMap.java:595) 
> at java.util.HashSet.contains(HashSet.java:203) 
> at 
> java.util.Collections$UnmodifiableCollection.contains(Collections.java:1032) 
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.apply(IgniteCacheOffheapManagerImpl.java:339)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.apply(IgniteCacheOffheapManagerImpl.java:337)
> at 
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNext:@TransformFilteringIterator.java:90)
> at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
>  
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.cacheEntriesCount(IgniteCacheOffheapManagerImpl.java:293)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsImpl.getOffHeapPrimaryEntriesCount(CacheMetricsImpl.java:240)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsSnapshot.(CacheMetricsSnapshot.java:271)
>  
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.localMetrics(GridCacheAdapter.java:3217)
>  
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1151)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.nonHeapMemoryUsed(GridDiscoveryManager.java:1121)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.metrics(GridDiscoveryManager.java:1087)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNode.metrics(TcpDiscoveryNode.java:269)
>  
> at 
> org.apache.ignite.internal.IgniteKernal$3.run(IgniteKernal.java:1175) 
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask.onTimeout(GridTimeoutProcessor.java:256)
> - locked <0x7f115f5bf890> (a 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask)
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:158)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Updated] (IGNITE-6923) Cache metrics are updated in timeout-worker potentially delaying critical code execution due to current implementation issues.

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6923:
-
Labels: iep-6  (was: )

> Cache metrics are updated in timeout-worker potentially delaying critical 
> code execution due to current implementation issues.
> --
>
> Key: IGNITE-6923
> URL: https://issues.apache.org/jira/browse/IGNITE-6923
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>  Labels: iep-6
> Fix For: 2.4
>
>
> Some metrics are using cache iteration for calculation. If number of caches 
> rather large this can be slow.
> Similar code is running in discovery thread.
> See stack trace for example.
> {noformat}
> "grid-timeout-worker-#39%DPL_GRID%DplGridNodeName%" #152 prio=5 os_prio=0 
> tid=0x7f1009a03000 nid=0x5caa runnable [0x7f0f059d9000] 
>java.lang.Thread.State: RUNNABLE 
> at java.util.HashMap.containsKey(HashMap.java:595) 
> at java.util.HashSet.contains(HashSet.java:203) 
> at 
> java.util.Collections$UnmodifiableCollection.contains(Collections.java:1032) 
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.apply(IgniteCacheOffheapManagerImpl.java:339)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.apply(IgniteCacheOffheapManagerImpl.java:337)
> at 
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNext:@TransformFilteringIterator.java:90)
> at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
>  
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.cacheEntriesCount(IgniteCacheOffheapManagerImpl.java:293)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsImpl.getOffHeapPrimaryEntriesCount(CacheMetricsImpl.java:240)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsSnapshot.(CacheMetricsSnapshot.java:271)
>  
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.localMetrics(GridCacheAdapter.java:3217)
>  
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1151)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.nonHeapMemoryUsed(GridDiscoveryManager.java:1121)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.metrics(GridDiscoveryManager.java:1087)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNode.metrics(TcpDiscoveryNode.java:269)
>  
> at 
> org.apache.ignite.internal.IgniteKernal$3.run(IgniteKernal.java:1175) 
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask.onTimeout(GridTimeoutProcessor.java:256)
> - locked <0x7f115f5bf890> (a 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask)
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:158)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Commented] (IGNITE-6868) Implement new JMX metrics for TcpCommunicationSpi monitoring

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6868:
-

If we bothered with binary compatibility of {{CommunicationSpi}} interface, 
then we can leave methods inside {{TcpCommunicationSpi}} and simply add unit 
tests for them.

> Implement new JMX metrics for TcpCommunicationSpi monitoring
> 
>
> Key: IGNITE-6868
> URL: https://issues.apache.org/jira/browse/IGNITE-6868
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented in TcpCommunicationSpi MBean:
> * Received messages count grouped by message type
> * Received messages count grouped by sender node
> * Sent messages count grouped by message type
> * Sent messages count grouped by receiver node



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

[jira] [Commented] (IGNITE-6868) Implement new JMX metrics for TcpCommunicationSpi monitoring

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6868:
-

[~alex_pl], [~avinogradov], it is not very clear why we removed aforementioned 
4 methods from {{TcpCommunicationSpi}} instead of simply adding their 
signatures to {{CommunicationSpi}}. This makes API inconsistent.

> Implement new JMX metrics for TcpCommunicationSpi monitoring
> 
>
> Key: IGNITE-6868
> URL: https://issues.apache.org/jira/browse/IGNITE-6868
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented in TcpCommunicationSpi MBean:
> * Received messages count grouped by message type
> * Received messages count grouped by sender node
> * Sent messages count grouped by message type
> * Sent messages count grouped by receiver node



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

[jira] [Assigned] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-6999:
--

Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Vasiliy Sisko
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



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

[jira] [Commented] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6999:


Please exclude spring logs from output

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



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

[jira] [Commented] (IGNITE-6867) Implement new JMX metrics for topology monitoring

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6867:
-

[~alex_pl], looks good to me.

> Implement new JMX metrics for topology monitoring
> -
>
> Key: IGNITE-6867
> URL: https://issues.apache.org/jira/browse/IGNITE-6867
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics and methods should be implemented:
> * Current topology version
> * Total server nodes count
> * Total client nodes count
> * Method to count nodes filtered by some node attribute
> * Method to count nodes grouped by some node attribute
>  
> There is already a ticket to implement first 2 metrics from this list 
> (IGNITE-6844)



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

[jira] [Commented] (IGNITE-7109) .NET: Thin client: Async cache operations

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7109:


Ticket for further optimization: IGNITE-7115

> .NET: Thin client: Async cache operations
> -
>
> Key: IGNITE-7109
> URL: https://issues.apache.org/jira/browse/IGNITE-7109
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Add async operations to {{ICacheClient}}.
> Thin client suppots asynchrony with requestId mechanism. Make sure it works 
> with .NET.



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

[jira] [Assigned] (IGNITE-7039) SQL: local query should pin affected partitions

[Roman Kondakov (JIRA)]

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

Roman Kondakov reassigned IGNITE-7039:
--

Assignee: Roman Kondakov

> SQL: local query should pin affected partitions
> ---
>
> Key: IGNITE-7039
> URL: https://issues.apache.org/jira/browse/IGNITE-7039
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>
> When distributed query is executed, we pin cache partitions for particular 
> topology version on map nodes [1]. However, it seems that we do no do that 
> for local queries. This is a bug because partition with required data could 
> be evicted from local node at any time, leading to incorrect results.
> [1] 
> https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288



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

[jira] [Assigned] (IGNITE-6343) Index is not used properly if changing sort order.

[Roman Kondakov (JIRA)]

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

Roman Kondakov reassigned IGNITE-6343:
--

Assignee: Roman Kondakov

> Index is not used properly if changing sort order.
> --
>
> Key: IGNITE-6343
> URL: https://issues.apache.org/jira/browse/IGNITE-6343
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Roman Kondakov
>  Labels: performance
>
> Unit test reproducer:
> {noformat}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.internal.processors.cache;
> import java.util.Calendar;
> import java.util.Collections;
> import java.util.Date;
> import java.util.LinkedHashMap;
> import java.util.List;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.QueryEntity;
> import org.apache.ignite.cache.QueryIndex;
> import org.apache.ignite.cache.QueryIndexType;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.configuration.MemoryPolicyConfiguration;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
> import static java.util.Calendar.*;
> /**
>  * Tests for cache query results serialization.
>  */
> public class GridCacheQueryIndexUsageSelfTest extends GridCommonAbstractTest {
> /** */
> private static final int GRID_CNT = 1;
> /** */
> private static final String CACHE_NAME = "A";
> /** */
> private static final CacheMode CACHE_MODE = PARTITIONED;
> /** */
> private static TcpDiscoveryIpFinder ipFinder = new 
> TcpDiscoveryVmIpFinder(true);
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> startGridsMultiThreaded(GRID_CNT);
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> MemoryPolicyConfiguration mpcfg = new MemoryPolicyConfiguration();
> //mpcfg.setMaxSize(2 * 1024 * 1024 * 1024L);
> mpcfg.setName("def");
> MemoryConfiguration mcfg = new MemoryConfiguration();
> mcfg.setDefaultMemoryPolicyName("def");
> mcfg.setMemoryPolicies(mpcfg);
> cfg.setMemoryConfiguration(mcfg);
> TcpDiscoverySpi disco = new TcpDiscoverySpi();
> disco.setIpFinder(ipFinder);
> cfg.setDiscoverySpi(disco);
> CacheConfiguration cacheCfg = defaultCacheConfiguration();
> cacheCfg.setName(CACHE_NAME);
> cacheCfg.setCacheMode(CACHE_MODE);
> cacheCfg.setWriteSynchronizationMode(FULL_SYNC);
> QueryEntity qe = new QueryEntity();
> qe.setKeyType(Long.class.getName());
> qe.setValueType(IndexedValue.class.getName());
> LinkedHashMap fields = U.newLinkedHashMap(3);
> fields.put("id", Long.class.getName());
> fields.put("startDate", Date.class.getName());
> qe.setFields(fields);
> QueryIndex idx = new QueryIndex();
> idx.setIndexType(QueryIndexType.SORTED);
> LinkedHashMap idxFields = 

[jira] [Closed] (IGNITE-7045) Client queries should throw a correct exception

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7045.
---

> Client queries should throw a correct exception
> ---
>
> Key: IGNITE-7045
> URL: https://issues.apache.org/jira/browse/IGNITE-7045
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>
> The following test being added to 
> org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:
> /**
>  * Method verifies that in the case of client query index is not used and 
> a correct exception is thrown.
>  *
>  * @throws Exception If failed.
>  */
> public void testClientOnlyNodeIndexException() throws Exception {
> try {
> Ignite g = startGrid("client");
> IgniteCache c = jcache(g, Integer.class, 
> Integer.class);
> try {
> List cres = c.query(new SqlFieldsQuery("select 
> count(*) from Integer")
> .setLocal(true)).getAll();
> } 
> catch (IgniteException e) {
> throw e; // FIXME: put an exception-checking code here 
> instead of throw
> }
> }
> finally {
> stopGrid("client");
> }
> }
> ...will result in NPE instead of an Ignite exception explaining the 
> appropriate cause.



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

[jira] [Resolved] (IGNITE-7045) Client queries should throw a correct exception

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-7045.
-
Resolution: Duplicate

> Client queries should throw a correct exception
> ---
>
> Key: IGNITE-7045
> URL: https://issues.apache.org/jira/browse/IGNITE-7045
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>
> The following test being added to 
> org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:
> /**
>  * Method verifies that in the case of client query index is not used and 
> a correct exception is thrown.
>  *
>  * @throws Exception If failed.
>  */
> public void testClientOnlyNodeIndexException() throws Exception {
> try {
> Ignite g = startGrid("client");
> IgniteCache c = jcache(g, Integer.class, 
> Integer.class);
> try {
> List cres = c.query(new SqlFieldsQuery("select 
> count(*) from Integer")
> .setLocal(true)).getAll();
> } 
> catch (IgniteException e) {
> throw e; // FIXME: put an exception-checking code here 
> instead of throw
> }
> }
> finally {
> stopGrid("client");
> }
> }
> ...will result in NPE instead of an Ignite exception explaining the 
> appropriate cause.



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

[jira] [Closed] (IGNITE-7014) SQL: in-place update should be allowed when indexing is enabled

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7014.
---

> SQL: in-place update should be allowed when indexing is enabled
> ---
>
> Key: IGNITE-7014
> URL: https://issues.apache.org/jira/browse/IGNITE-7014
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> See {{IgniteCacheOffheapManagerImpl.canUpdateOldRow}} - if cache has at least 
> one query entity, in-place updates are not possible. This drastically reduces 
> performance of DML and regular update (cache API) operations. 
> We need to understand whether any explanation of this restriction exists. In 
> any case, in-place updates should be allowed for SQL-enabled caches.



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

[jira] [Resolved] (IGNITE-7014) SQL: in-place update should be allowed when indexing is enabled

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-7014.
-
Resolution: Won't Fix

> SQL: in-place update should be allowed when indexing is enabled
> ---
>
> Key: IGNITE-7014
> URL: https://issues.apache.org/jira/browse/IGNITE-7014
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> See {{IgniteCacheOffheapManagerImpl.canUpdateOldRow}} - if cache has at least 
> one query entity, in-place updates are not possible. This drastically reduces 
> performance of DML and regular update (cache API) operations. 
> We need to understand whether any explanation of this restriction exists. In 
> any case, in-place updates should be allowed for SQL-enabled caches.



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