[jira] [Commented] (IGNITE-7182) Slow sorting of pages collection on checkpoint begin can cause zero dropdown even with throttling enabled

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7182:


GitHub user dspavlov opened a pull request:

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

IGNITE-7182: throttle only changes

Part of implementation changes throttling policy

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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-7182-throttle-only

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

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


commit dd8a7ac47df1dc401e5a98dc21f9a0988fb50b0f
Author: dpavlov 
Date:   2017-12-01T16:47:45Z

GG-13117: PDS compatibility test flaky failure: debug code added

commit 6c7b4fb24542672944220dca94efffa94a969ee2
Author: dspavlov 
Date:   2017-12-16T07:49:42Z

IGNITE-7182: Throttle only changes, fixes too aggressive throttling at CP 
begin




> Slow sorting of pages collection on checkpoint begin can cause zero dropdown 
> even with throttling enabled
> -
>
> Key: IGNITE-7182
> URL: https://issues.apache.org/jira/browse/IGNITE-7182
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Ivan Rakov
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> Tests show that GridCacheDatabaseSharedManager#splitAndSortCpPagesIfNeeded 
> call can last several seconds on nodes with big amount of memory (>10GB). We 
> should optimize sorting algorithm, possibly making it multithreaded.
> Another option to make pages write throttling more smooth is to get rid of 
> this heuristic:
> {noformat}
> // Starting with 0.05 to avoid throttle right after 
> checkpoint start
> // 7/12 is maximum ratio of dirty pages
> dirtyRatioThreshold = (dirtyRatioThreshold * 0.95 + 0.05) * 7 
> / 12;
> {noformat}
> We should replace "magic" lower bound 0.05 * 7 / 12 with the real percentage 
> of dirty pages at the moment of 
> GridCacheDatabaseSharedManager.Checkpointer#markCheckpointBegin call return.



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

[jira] [Assigned] (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:all-tabpanel
 ]

Nikolay Izhikov reassigned IGNITE-6903:
---

Assignee: (was: Nikolay Izhikov)

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



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

[jira] [Created] (IGNITE-7217) Add abilities to monitor custom thread pools

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-7217:
---

 Summary: Add abilities to monitor custom thread pools
 Key: IGNITE-7217
 URL: https://issues.apache.org/jira/browse/IGNITE-7217
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.3
Reporter: Valentin Kulichenko
 Fix For: 2.4


We have a periodic metrics logger that prints out different stats including the 
ones for public and system thread pools:
{noformat}
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=8, qSize=0]
{noformat}
However, is user configures a custom thread pools via 
{{IgniteConfiguration#setExecutorConfiguration}}, stats for these thread pools 
are not added. We also do not register MBeans for these pools.



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

[jira] [Created] (IGNITE-7216) Refactor examples project

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-7216:
-

 Summary: Refactor examples project
 Key: IGNITE-7216
 URL: https://issues.apache.org/jira/browse/IGNITE-7216
 Project: Ignite
  Issue Type: Sub-task
Reporter: Sergey Kozlov


Now we have regular and Java8 examples  and I suppose following:
* Replace regular examples by corresponding Java8 examples if any
* Remove Java8 profile
* Set source/target as for main project
* ML profile should be activated by default



--
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

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-7044:
---

Assignee: Denis Magda  (was: Prachi Garg)

Made minor edits.

> 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: Denis Magda
> 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] [Updated] (IGNITE-6903) Implement new JMX metrics for Indexing

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6903:

Component/s: sql

> Implement new JMX metrics for Indexing
> --
>
> Key: IGNITE-6903
> URL: https://issues.apache.org/jira/browse/IGNITE-6903
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: iep-6, important
> Fix For: 2.5
>
>
> 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-7213) Empty class descriptions for KNNModelFormat

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7213:


Github user asfgit closed the pull request at:

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


> Empty class descriptions for KNNModelFormat
> ---
>
> Key: IGNITE-7213
> URL: https://issues.apache.org/jira/browse/IGNITE-7213
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>Priority: Critical
> Fix For: 2.4
>
>
> Javadoc generation failed if we have classes with empty class-javadoc



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6903:

Fix Version/s: (was: 2.4)
   2.5

> 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.5
>
>
> 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-6903) Implement new JMX metrics for Indexing

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6903:
-

Guys, I would just keep this ticket open and put on hold waiting for inputs 
from [~vozerov]. Otherwise, we will open the same ticket in a couple of weeks 
or month when Vladimir finishes his research.

[~vozerov], please share your summary here when you're ready and link this 
ticket as dependent to any you may create.

> 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.5
>
>
> These additional metrics and methods should be implemented:
> - Space occupied by indexes.



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

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

[Denis Magda (JIRA)]

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

Denis Magda reopened IGNITE-6903:
-

> 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.5
>
>
> 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-7213) Empty class descriptions for KNNModelFormat

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7213:


GitHub user ybabak opened a pull request:

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

IGNITE-7213: Empty class descriptions for KNNModelFormat

fixed.

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

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

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

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


commit fefebd90dd1d13f4a4c6886eab97f12a19fca30d
Author: YuriBabak 
Date:   2017-12-15T17:07:44Z

IGNITE-7213: Empty class descriptions for KNNModelFormat

fixed.




> Empty class descriptions for KNNModelFormat
> ---
>
> Key: IGNITE-7213
> URL: https://issues.apache.org/jira/browse/IGNITE-7213
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Yury Babak
>Priority: Critical
> Fix For: 2.4
>
>
> Javadoc generation failed if we have classes with empty class-javadoc



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

[jira] [Created] (IGNITE-7215) Documentation bug: "Cross-cache Query" page is dead

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7215:


 Summary: Documentation bug: "Cross-cache Query" page is dead
 Key: IGNITE-7215
 URL: https://issues.apache.org/jira/browse/IGNITE-7215
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.3
Reporter: Alexey Kukushkin


Could not find "Cross-cache Queries" section in the latest Ignite 2.3 docs. The 
only page that references "cross-cache queries" is [JDBC Client 
Driver|https://apacheignite-sql.readme.io/docs#section-jdbc-client-driver] and 
it points to a [dead 
link|https://apacheignite-sql.readme.io/docs/cache-queries#cross-cache-queries]



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

[jira] [Commented] (IGNITE-7214) performance measurement for FCM and KNN algorithms

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-7214:


preliminary plan is to make benchmarks based on code in respective examples for 
mentioned algorithms

> performance measurement for FCM and KNN algorithms
> --
>
> Key: IGNITE-7214
> URL: https://issues.apache.org/jira/browse/IGNITE-7214
> 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 of Fuzzy c-means (FCM) and k 
> nearest neighbours (KNN) to avoid performance degradation. Also we need some 
> performance comparison with other ml libs.



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

[jira] [Created] (IGNITE-7214) performance measurement for FCM and KNN algorithms

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-7214:
--

 Summary: performance measurement for FCM and KNN algorithms
 Key: IGNITE-7214
 URL: https://issues.apache.org/jira/browse/IGNITE-7214
 Project: Ignite
  Issue Type: Task
  Components: ml, yardstick
Reporter: Oleg Ignatenko


We want to start tracking our performance of Fuzzy c-means (FCM) and k nearest 
neighbours (KNN) to avoid performance degradation. Also we need some 
performance comparison with other ml libs.



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

[jira] [Updated] (IGNITE-7214) performance measurement for FCM and KNN algorithms

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko updated IGNITE-7214:
---
Fix Version/s: 2.4

> performance measurement for FCM and KNN algorithms
> --
>
> Key: IGNITE-7214
> URL: https://issues.apache.org/jira/browse/IGNITE-7214
> Project: Ignite
>  Issue Type: Task
>  Components: ml, yardstick
>Reporter: Oleg Ignatenko
> Fix For: 2.4
>
>
> We want to start tracking our performance of Fuzzy c-means (FCM) and k 
> nearest neighbours (KNN) to avoid performance degradation. Also we need some 
> performance comparison with other ml libs.



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

[jira] [Assigned] (IGNITE-7214) performance measurement for FCM and KNN algorithms

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko reassigned IGNITE-7214:
--

Assignee: Oleg Ignatenko

> performance measurement for FCM and KNN algorithms
> --
>
> Key: IGNITE-7214
> URL: https://issues.apache.org/jira/browse/IGNITE-7214
> 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 of Fuzzy c-means (FCM) and k 
> nearest neighbours (KNN) to avoid performance degradation. Also we need some 
> performance comparison with other ml libs.



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

[jira] [Commented] (IGNITE-6736) Java 9: rework GridCacheMapEntry synchronization logic to avoid Unsafe.monitor* methods

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6736:
--

I've made a naïve benchmark to compare performance of {{ReentrantLock}} and 
Java monitor object synchronization in non-contended case. It was just a 
single-threaded loop incrementing long non-volatile field 10^9 times with 
various synchronizers. Results follow.

Java 8:
no sync: 1177ms
monitor/synchronized: 18804ms
monitor/unsafe: 64438ms
lock: 17103ms

Java 9:
no sync: 1183ms
monitor/synchronized: 18929ms
lock: 15193ms

I can't understand why {{ReentrantLock}} looks so good, but {{monitorEnter}} 
and {{monitorExit}} are definitely slow. Possibly, [1] describes a reason for 
this. Anyway, I'll change to locks with more confidence.

[1] 
http://jsr166-concurrency.10961.n7.nabble.com/synchronized-vs-Unsafe-monitorEnter-monitorExit-tp11764p11767.html

> Java 9: rework GridCacheMapEntry synchronization logic to avoid 
> Unsafe.monitor* methods
> ---
>
> Key: IGNITE-6736
> URL: https://issues.apache.org/jira/browse/IGNITE-6736
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> {{GridCacheMapEntry}} class rely on {{synchronized}} on itself heavily. In 
> {{ATOMIC}} caches we lock multiple entries at once using 
> {{Unsafe.monitorEnter/Exit}} methods. Unfortunately these methods were 
> removed in Java 9. Recursion is not an option, as it would cause stack 
> overflow for {{putAll}} operations with multiple entries.
> Possible fixes:
> 1) Rework {{synchronized}} to {{ReentrantLock}}. Easy, but may cause 
> additional memory pressure.
> 2) Have different implementations for Java 8 ({{synchronzied}}) and Java 9 
> ({{ReentrantLock}}) - much more complex solution, because we will require 
> separate module for Java 8 and Java 9.
> 3) Rework {{ATOMIC}} caches, so that {{putAll}} operation updates entries 
> one-by-one. As a side effect it will eliminate deadlocks.



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

[jira] [Created] (IGNITE-7213) Empty class descriptions for KNNModelFormat

[Yury Babak (JIRA)]

Yury Babak created IGNITE-7213:
--

 Summary: Empty class descriptions for KNNModelFormat
 Key: IGNITE-7213
 URL: https://issues.apache.org/jira/browse/IGNITE-7213
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak
Assignee: Yury Babak
Priority: Critical
 Fix For: 2.4


Javadoc generation failed if we have classes with empty class-javadoc



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

[jira] [Commented] (IGNITE-4490) Optimize DML for fast INSERT and MERGE

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4490:
-

[~vozerov]
No, at this point we shouldn't as this routine comes from how H2 converts dates 
internally and that logic does not involve Java 8 stuff - see 
{{org.h2.util.DateTimeUtils}} and its imports.

> Optimize DML for fast INSERT and MERGE
> --
>
> Key: IGNITE-4490
> URL: https://issues.apache.org/jira/browse/IGNITE-4490
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>  Labels: performance
>
> It's possible to avoid any SQL querying and map some INSERT and MERGE 
> statements to cache operations in a way similar to that of UPDATE and DELETE 
> - i.e. don't make queries when there are no expressions to evaluate in the 
> query and enhance update plans to perform direct cache operations when INSERT 
> and MERGE affect columns {{_key}} and {{_val}} only.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7097:


GitHub user oignatenko opened a pull request:

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

IGNITE-7097 performance measurement for SparseDistributedMatrix multi…

…plication

- optimised and unoptimised benchmarks, along with respective documentation
- also a common adjustment to matrix mul benchmarks to make these more 
sensitive to algorithmic changes
-- verified with diffs overview, clean rebuild, trial execution of the 
benchmarks and studying results

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

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

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

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


commit be918641730af3738dcc4d8cd608b63ba6088732
Author: Oleg Ignatenko 
Date:   2017-12-15T15:58:43Z

IGNITE-7097 performance measurement for SparseDistributedMatrix 
multiplication
- optimised and unoptimised benchmarks, along with respective documentation
- also a common adjustment to matrix mul benchmarks to make these more 
sensitive to algorithmic changes
-- verified with diffs overview, clean rebuild, trial execution of the 
benchmarks and studying results




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

Oleg Ignatenko edited comment on IGNITE-7097 at 12/15/17 4:01 PM:
--

Upon further study the root cause of the issue turned out that the 
implementation in this matrix type is very slow, much slower than in all other 
classes used in matrix mul benchmarks. Based on that the way to resolve this 
was chosen as follows: this benchmark runs on matrices of smaller size than 
other, plus it is complemented with a benchmark that uses regular size but also 
applies a trivial optimization by delegating multiplication to 
{{SparseBlockDistributedMatrix}}.

For the sake of completeness I also briefly discussed with Yury an option to 
somehow optimize multiplication in this type of matrix. As of now it doesn't 
look worth the effort. This is primarily because we already have a properly 
optimized block version of sparse distributed matrix, so is unclear what 
tangible benefits can be gained by such an optimization.


was (Author: oignatenko):
On a closer inspection the root cause of the issue turned out that the 
implementation in this matrix type is very slow, much slower than in all other 
classes used in matrix mul benchmarks. Based on that the way to resolve this 
was chosen as follows: this benchmark runs on matrices of smaller size than 
other, plus it is complemented with a benchmark that uses regular size but also 
applies a trivial optimization by delegating multiplication to 
{{SparseBlockDistributedMatrix}}.

For the sake of completeness I also briefly discussed with Yury an option to 
somehow optimize multiplication in this type of matrix. As of now it doesn't 
look worth the effort. This is primarily because we already have a properly 
optimized block version of sparse distributed matrix, so is unclear what 
tangible benefits can be gained by such an optimization.

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

Oleg Ignatenko commented on IGNITE-7097:


On a closer inspection the root cause of the issue turned out that the 
implementation in this matrix type is very slow, much slower than in all other 
classes used in matrix mul benchmarks. Based on that the way to resolve this 
was chosen as follows: this benchmark runs on matrices of smaller size than 
other, plus it is complemented with a benchmark that uses regular size but also 
applies a trivial optimization by delegating multiplication to 
{{SparseBlockDistributedMatrix}}.

For the sake of completeness I also briefly discussed with Yury an option to 
somehow optimize multiplication in this type of matrix. As of now it doesn't 
look worth the effort. This is primarily because we already have a properly 
optimized block version of sparse distributed matrix, so is unclear what 
tangible benefits can be gained by such an optimization.

> 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-7203) Java 8 by default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7203:


GitHub user vveider opened a pull request:

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

IGNITE-7203 Java 8 by default



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

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

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

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


commit 1fd200e5ca712f7ce306807904cccd8b72e171ea
Author: Ivanov Petr 
Date:   2017-12-15T14:35:35Z

IGNITE-7203 Java 8 by default
 * got rid of java-1.8 related profiles
 * remove ml profile and included ml build into main reactor
 * added master properties to maven-compiler-plugin for whole project to be 
compiled only by java-1.8
 * refactored met properties + gathered them in parent module

commit a4db11b84622ec6960de3f44502cf08abe3dc650
Author: Ivanov Petr 
Date:   2017-12-15T15:17:59Z

IGNITE-7203 Java 8 by default
 * refactored examples module: merged java8 and java packages




> Java 8 by default
> -
>
> Key: IGNITE-7203
> URL: https://issues.apache.org/jira/browse/IGNITE-7203
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Peter Ivanov
> Fix For: 2.4
>
>
> We should drop Java 7 support.
> 1) We should 
> - get rid of java8 profiles
> - relocate tests and sources with *.java8.* package to regular sources
> - set 
> {noformat}
>  1.8
>  1.8
> {noformat} 
> by default
> 2) Release process
> https://ci.ignite.apache.org/project.html?projectId=AssemblyAndRelease
> should be updated if necessary.



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

[jira] [Closed] (IGNITE-7212) Load stoped after server node kill

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov closed IGNITE-7212.


Fix confirmed

> Load stoped after server node kill
> --
>
> Key: IGNITE-7212
> URL: https://issues.apache.org/jira/browse/IGNITE-7212
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Ilya Suntsov
>Assignee: Ilya Suntsov
>Priority: Critical
> Attachments: cfg_log_master_1.zip
>
>
> Scenario:
> * Start 4 servers
> * Start load tasks on 5 clients
> * Kill 1 server
> * Waiting for rebalancing
> * Kill 1 server
> Result:
> After the kill of second servers node load stoped.
> In servers logs I see messages like this:
> {noformat}
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Remote client 
> closed connection: GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
> [super=AbstractNioClientWorker [idx=0, bytesRcvd=130952565, 
> bytesSent=131203245, bytesRcvd0=3069200, bytesSent0=3068083, select=true, 
> super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null, 
> finished=false, hashCode=1748650517, interrupted=false, 
> runner=grid-nio-worker-tcp-comm-0-#41]]], 
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> inRecovery=GridNioRecoveryDescriptor [acked=1024, resendCnt=0, rcvCnt=1026, 
> sentCnt=1029, reserved=true, lastAck=1024, nodeLeft=false, 
> node=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], outRecovery=GridNioRecoveryDescriptor 
> [acked=1024, resendCnt=0, rcvCnt=1026, sentCnt=1029, reserved=true, 
> lastAck=1024, nodeLeft=false, node=TcpDiscoveryNode 
> [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], super=GridNioSessionImpl 
> [locAddr=/172.31.23.220:41732, 
> rmtAddr=ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47100, 
> createTime=1513335774008, closeTime=0, bytesSent=131203245, 
> bytesRcvd=130952565, bytesSent0=3068083, bytesRcvd0=3069200, 
> sndSchedTime=1513335774008, lastSndTime=1513337029027, 
> lastRcvTime=1513337029027, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter 
> [parser=org.apache.ignite.internal.util.nio.GridDirectParser@11ae7d3b, 
> directMode=true], GridConnectionBytesVerifyFilter], accepted=false]]
> [2017-12-15 11:23:50][WARN ][tcp-disco-msg-worker-#2] Failed to send message 
> to next node [msg=TcpDiscoveryConnectionCheckMessage 
> [super=TcpDiscoveryAbstractMessage [sndNodeId=null, 
> id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, verifierNodeId=null, 
> topVer=0, pendingIdx=0, failedNodes=null, isClient=false]], 
> next=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], errMsg=Failed to send message to next node 
> [msg=TcpDiscoveryConnectionCheckMessage [super=TcpDiscoveryAbstractMessage 
> [sndNodeId=null, id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, 
> verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, 
> isClient=false]], next=ClusterNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> order=1, addr=[127.0.0.1, 172.31.20.3], daemon=false]]]
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Session was 
> closed but there are unacknowledged messages, will try to reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Recovery reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Creating NIO client to node: 
> TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 
> 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> 

[jira] [Assigned] (IGNITE-7212) Load stoped after server node kill

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-7212:


Assignee: Ilya Suntsov  (was: Alexey Goncharuk)

> Load stoped after server node kill
> --
>
> Key: IGNITE-7212
> URL: https://issues.apache.org/jira/browse/IGNITE-7212
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Ilya Suntsov
>Assignee: Ilya Suntsov
>Priority: Critical
> Attachments: cfg_log_master_1.zip
>
>
> Scenario:
> * Start 4 servers
> * Start load tasks on 5 clients
> * Kill 1 server
> * Waiting for rebalancing
> * Kill 1 server
> Result:
> After the kill of second servers node load stoped.
> In servers logs I see messages like this:
> {noformat}
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Remote client 
> closed connection: GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
> [super=AbstractNioClientWorker [idx=0, bytesRcvd=130952565, 
> bytesSent=131203245, bytesRcvd0=3069200, bytesSent0=3068083, select=true, 
> super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null, 
> finished=false, hashCode=1748650517, interrupted=false, 
> runner=grid-nio-worker-tcp-comm-0-#41]]], 
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> inRecovery=GridNioRecoveryDescriptor [acked=1024, resendCnt=0, rcvCnt=1026, 
> sentCnt=1029, reserved=true, lastAck=1024, nodeLeft=false, 
> node=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], outRecovery=GridNioRecoveryDescriptor 
> [acked=1024, resendCnt=0, rcvCnt=1026, sentCnt=1029, reserved=true, 
> lastAck=1024, nodeLeft=false, node=TcpDiscoveryNode 
> [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], super=GridNioSessionImpl 
> [locAddr=/172.31.23.220:41732, 
> rmtAddr=ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47100, 
> createTime=1513335774008, closeTime=0, bytesSent=131203245, 
> bytesRcvd=130952565, bytesSent0=3068083, bytesRcvd0=3069200, 
> sndSchedTime=1513335774008, lastSndTime=1513337029027, 
> lastRcvTime=1513337029027, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter 
> [parser=org.apache.ignite.internal.util.nio.GridDirectParser@11ae7d3b, 
> directMode=true], GridConnectionBytesVerifyFilter], accepted=false]]
> [2017-12-15 11:23:50][WARN ][tcp-disco-msg-worker-#2] Failed to send message 
> to next node [msg=TcpDiscoveryConnectionCheckMessage 
> [super=TcpDiscoveryAbstractMessage [sndNodeId=null, 
> id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, verifierNodeId=null, 
> topVer=0, pendingIdx=0, failedNodes=null, isClient=false]], 
> next=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], errMsg=Failed to send message to next node 
> [msg=TcpDiscoveryConnectionCheckMessage [super=TcpDiscoveryAbstractMessage 
> [sndNodeId=null, id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, 
> verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, 
> isClient=false]], next=ClusterNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> order=1, addr=[127.0.0.1, 172.31.20.3], daemon=false]]]
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Session was 
> closed but there are unacknowledged messages, will try to reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Recovery reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Creating NIO client to node: 
> TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 
> 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> 

[jira] [Updated] (IGNITE-5874) Store TTL expire times in B+ tree on per-partition basis

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5874:
-
Fix Version/s: 2.4

> Store TTL expire times in B+ tree on per-partition basis
> 
>
> Key: IGNITE-5874
> URL: https://issues.apache.org/jira/browse/IGNITE-5874
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrew Mashenkov
> Fix For: 2.4
>
> Attachments: IgnitePdsWithTtlTest.java
>
>
> TTL expire times for entries are stored in PendingEntriesTree, which is 
> singleton for cache. When expiration occurs, all system threads iterate 
> through the tree in order to remove expired entries. Iterating through single 
> tree causes contention and perfomance loss. 
> Related performance issue: https://issues.apache.org/jira/browse/IGNITE-5793
> We should keep instance of PendingEntriesTree for each partition, like we do 
> for CacheDataTree.



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

[jira] [Resolved] (IGNITE-7212) Load stoped after server node kill

[Alexey Goncharuk (JIRA)]

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

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

Fixed in master.

> Load stoped after server node kill
> --
>
> Key: IGNITE-7212
> URL: https://issues.apache.org/jira/browse/IGNITE-7212
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Ilya Suntsov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Attachments: cfg_log_master_1.zip
>
>
> Scenario:
> * Start 4 servers
> * Start load tasks on 5 clients
> * Kill 1 server
> * Waiting for rebalancing
> * Kill 1 server
> Result:
> After the kill of second servers node load stoped.
> In servers logs I see messages like this:
> {noformat}
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Remote client 
> closed connection: GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
> [super=AbstractNioClientWorker [idx=0, bytesRcvd=130952565, 
> bytesSent=131203245, bytesRcvd0=3069200, bytesSent0=3068083, select=true, 
> super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null, 
> finished=false, hashCode=1748650517, interrupted=false, 
> runner=grid-nio-worker-tcp-comm-0-#41]]], 
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> inRecovery=GridNioRecoveryDescriptor [acked=1024, resendCnt=0, rcvCnt=1026, 
> sentCnt=1029, reserved=true, lastAck=1024, nodeLeft=false, 
> node=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], outRecovery=GridNioRecoveryDescriptor 
> [acked=1024, resendCnt=0, rcvCnt=1026, sentCnt=1029, reserved=true, 
> lastAck=1024, nodeLeft=false, node=TcpDiscoveryNode 
> [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], super=GridNioSessionImpl 
> [locAddr=/172.31.23.220:41732, 
> rmtAddr=ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47100, 
> createTime=1513335774008, closeTime=0, bytesSent=131203245, 
> bytesRcvd=130952565, bytesSent0=3068083, bytesRcvd0=3069200, 
> sndSchedTime=1513335774008, lastSndTime=1513337029027, 
> lastRcvTime=1513337029027, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter 
> [parser=org.apache.ignite.internal.util.nio.GridDirectParser@11ae7d3b, 
> directMode=true], GridConnectionBytesVerifyFilter], accepted=false]]
> [2017-12-15 11:23:50][WARN ][tcp-disco-msg-worker-#2] Failed to send message 
> to next node [msg=TcpDiscoveryConnectionCheckMessage 
> [super=TcpDiscoveryAbstractMessage [sndNodeId=null, 
> id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, verifierNodeId=null, 
> topVer=0, pendingIdx=0, failedNodes=null, isClient=false]], 
> next=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], errMsg=Failed to send message to next node 
> [msg=TcpDiscoveryConnectionCheckMessage [super=TcpDiscoveryAbstractMessage 
> [sndNodeId=null, id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, 
> verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, 
> isClient=false]], next=ClusterNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> order=1, addr=[127.0.0.1, 172.31.20.3], daemon=false]]]
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Session was 
> closed but there are unacknowledged messages, will try to reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Recovery reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Creating NIO client to node: 
> TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 
> 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, 

[jira] [Updated] (IGNITE-6952) Ignite fails to start on non x86/64 architectures

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov updated IGNITE-6952:
-
Description: 
Ignite fails on AIX with the following stack trace:

{noformat}
java.lang.IllegalArgumentException: null 
at java.nio.Buffer.position(Buffer.java:255) ~[?:1.8.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readArrayLE(DirectByteBufferStreamImplV2.java:1587)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readArrayLE(DirectByteBufferStreamImplV2.java:1542)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readLongArray(DirectByteBufferStreamImplV2.java:1013)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.DirectMessageReader.readLongArray(DirectMessageReader.java:212)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.GridLongList.readFrom(GridLongList.java:558) 
~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.read(DirectByteBufferStreamImplV2.java:1785)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readCollection(DirectByteBufferStreamImplV2.java:1244)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.DirectMessageReader.readCollection(DirectMessageReader.java:333)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.CacheGroupAffinityMessage.readFrom(CacheGroupAffinityMessage.java:292)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.read(DirectByteBufferStreamImplV2.java:1785)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMap(DirectByteBufferStreamImplV2.java:1294)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.DirectMessageReader.readMap(DirectMessageReader.java:345)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsFullMessage.readFrom(GridDhtPartitionsFullMessage.java:645)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.direct.DirectMessageReader.readMessage(DirectMessageReader.java:311)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:262)
 ~[ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:90)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:133)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3388)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1261)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
 [ignite-core-2.3.0.jar:2.3.0] 
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
 [ignite-core-2.3.0.jar:2.3.0] 
at 

[jira] [Assigned] (IGNITE-5623) DDL needs to support DEFAULT operator

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-5623:


Assignee: Taras Ledkov

> DDL needs to support DEFAULT operator 
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>  Labels: important
>
> There should be a way to set a default value for a column/field if the one is 
> not specified during an insert operation. In general, we need to support 
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
>   ID int,
>   FirstName varchar(255),
>   Age int,
>   City varchar(255) DEFAULT 'Sandnes'
> );
> {code}



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

[jira] [Commented] (IGNITE-7212) Load stoped after server node kill

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7212:
--

The issue is related to 
org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java:3110
We loop forever here. This is a regression introduced by IGNITE-6639.

> Load stoped after server node kill
> --
>
> Key: IGNITE-7212
> URL: https://issues.apache.org/jira/browse/IGNITE-7212
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Ilya Suntsov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Attachments: cfg_log_master_1.zip
>
>
> Scenario:
> * Start 4 servers
> * Start load tasks on 5 clients
> * Kill 1 server
> * Waiting for rebalancing
> * Kill 1 server
> Result:
> After the kill of second servers node load stoped.
> In servers logs I see messages like this:
> {noformat}
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Remote client 
> closed connection: GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
> [super=AbstractNioClientWorker [idx=0, bytesRcvd=130952565, 
> bytesSent=131203245, bytesRcvd0=3069200, bytesSent0=3068083, select=true, 
> super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null, 
> finished=false, hashCode=1748650517, interrupted=false, 
> runner=grid-nio-worker-tcp-comm-0-#41]]], 
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> inRecovery=GridNioRecoveryDescriptor [acked=1024, resendCnt=0, rcvCnt=1026, 
> sentCnt=1029, reserved=true, lastAck=1024, nodeLeft=false, 
> node=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], outRecovery=GridNioRecoveryDescriptor 
> [acked=1024, resendCnt=0, rcvCnt=1026, sentCnt=1029, reserved=true, 
> lastAck=1024, nodeLeft=false, node=TcpDiscoveryNode 
> [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], super=GridNioSessionImpl 
> [locAddr=/172.31.23.220:41732, 
> rmtAddr=ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47100, 
> createTime=1513335774008, closeTime=0, bytesSent=131203245, 
> bytesRcvd=130952565, bytesSent0=3068083, bytesRcvd0=3069200, 
> sndSchedTime=1513335774008, lastSndTime=1513337029027, 
> lastRcvTime=1513337029027, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter 
> [parser=org.apache.ignite.internal.util.nio.GridDirectParser@11ae7d3b, 
> directMode=true], GridConnectionBytesVerifyFilter], accepted=false]]
> [2017-12-15 11:23:50][WARN ][tcp-disco-msg-worker-#2] Failed to send message 
> to next node [msg=TcpDiscoveryConnectionCheckMessage 
> [super=TcpDiscoveryAbstractMessage [sndNodeId=null, 
> id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, verifierNodeId=null, 
> topVer=0, pendingIdx=0, failedNodes=null, isClient=false]], 
> next=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], errMsg=Failed to send message to next node 
> [msg=TcpDiscoveryConnectionCheckMessage [super=TcpDiscoveryAbstractMessage 
> [sndNodeId=null, id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, 
> verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, 
> isClient=false]], next=ClusterNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> order=1, addr=[127.0.0.1, 172.31.20.3], daemon=false]]]
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Session was 
> closed but there are unacknowledged messages, will try to reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Recovery reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Creating NIO client to node: 
> TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 
> 172.31.20.3], 
> 

[jira] [Assigned] (IGNITE-7212) Load stoped after server node kill

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-7212:


Assignee: Alexey Goncharuk

> Load stoped after server node kill
> --
>
> Key: IGNITE-7212
> URL: https://issues.apache.org/jira/browse/IGNITE-7212
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Ilya Suntsov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Attachments: cfg_log_master_1.zip
>
>
> Scenario:
> * Start 4 servers
> * Start load tasks on 5 clients
> * Kill 1 server
> * Waiting for rebalancing
> * Kill 1 server
> Result:
> After the kill of second servers node load stoped.
> In servers logs I see messages like this:
> {noformat}
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Remote client 
> closed connection: GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
> [super=AbstractNioClientWorker [idx=0, bytesRcvd=130952565, 
> bytesSent=131203245, bytesRcvd0=3069200, bytesSent0=3068083, select=true, 
> super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null, 
> finished=false, hashCode=1748650517, interrupted=false, 
> runner=grid-nio-worker-tcp-comm-0-#41]]], 
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> inRecovery=GridNioRecoveryDescriptor [acked=1024, resendCnt=0, rcvCnt=1026, 
> sentCnt=1029, reserved=true, lastAck=1024, nodeLeft=false, 
> node=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], outRecovery=GridNioRecoveryDescriptor 
> [acked=1024, resendCnt=0, rcvCnt=1026, sentCnt=1029, reserved=true, 
> lastAck=1024, nodeLeft=false, node=TcpDiscoveryNode 
> [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], super=GridNioSessionImpl 
> [locAddr=/172.31.23.220:41732, 
> rmtAddr=ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47100, 
> createTime=1513335774008, closeTime=0, bytesSent=131203245, 
> bytesRcvd=130952565, bytesSent0=3068083, bytesRcvd0=3069200, 
> sndSchedTime=1513335774008, lastSndTime=1513337029027, 
> lastRcvTime=1513337029027, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter 
> [parser=org.apache.ignite.internal.util.nio.GridDirectParser@11ae7d3b, 
> directMode=true], GridConnectionBytesVerifyFilter], accepted=false]]
> [2017-12-15 11:23:50][WARN ][tcp-disco-msg-worker-#2] Failed to send message 
> to next node [msg=TcpDiscoveryConnectionCheckMessage 
> [super=TcpDiscoveryAbstractMessage [sndNodeId=null, 
> id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, verifierNodeId=null, 
> topVer=0, pendingIdx=0, failedNodes=null, isClient=false]], 
> next=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], errMsg=Failed to send message to next node 
> [msg=TcpDiscoveryConnectionCheckMessage [super=TcpDiscoveryAbstractMessage 
> [sndNodeId=null, id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, 
> verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, 
> isClient=false]], next=ClusterNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> order=1, addr=[127.0.0.1, 172.31.20.3], daemon=false]]]
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Session was 
> closed but there are unacknowledged messages, will try to reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Recovery reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Creating NIO client to node: 
> TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 
> 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, 

[jira] [Assigned] (IGNITE-5580) Improve node failure cause information

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii reassigned IGNITE-5580:
--

Assignee: Ryabov Dmitrii

> Improve node failure cause information
> --
>
> Key: IGNITE-5580
> URL: https://issues.apache.org/jira/browse/IGNITE-5580
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Ryabov Dmitrii
>  Labels: observability
>
> When a node fails, we do not print out any information about the root cause 
> of this failure. This makes it extremely hard to investigate the failure 
> causes - I need to find a previous node for the failed node and check the 
> logs on the previous node.
> I suggest that we add extensive information about the reason of the node 
> failure and the sequence of events that led to this, e.g.:
> [time] [NODE] Sending a message to next node - failed _because_ - write 
> timeout, read timeout, ...?
> [time] [NODE] Connection check - failed - why? Connection refused, handshake 
> timed out, ...?
> ...
> [time] [NODE] Decided to drop the node because of the sequence above
> Maybe we do not need to print out this information always, but we do need 
> this when troubleshooting logger is enabled.
> Also, DiscoverySpi should collect a set of latest important events and dump 
> these events in case of local node segmentation. This will allow users to 
> match the events in the cluster and events on local node and get to the 
> bottom of the failure.



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

[jira] [Commented] (IGNITE-6740) Java 9: rework DirectBuffer.address() usages

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev commented on IGNITE-6740:
---

[~andrey-kuznetsov], I think this should work. Now it looks good to me.

> Java 9: rework DirectBuffer.address() usages
> 
>
> Key: IGNITE-6740
> URL: https://issues.apache.org/jira/browse/IGNITE-6740
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> We have two usages of {{DirectBuffer.address()}} method which is no longer 
> accessible in Java 9: 
> 1) {{DirectByteBufferStreamImplV1}}
> 2) {{DirectByteBufferStreamImplV2}}
> Need to rework this code using reflection and/or {{Unsafe}}, so that it 
> compiles and work on all Java versions.



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

[jira] [Commented] (IGNITE-7074) NPE when WAL path and WAL archive path are the same

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-7074:


[~dpavlov], [~danellis], this ticket duplicates 
[IGNITE-6802|https://issues.apache.org/jira/browse/IGNITE-6802].

> NPE when WAL path and WAL archive path are the same
> ---
>
> Key: IGNITE-7074
> URL: https://issues.apache.org/jira/browse/IGNITE-7074
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.2, 2.3
>Reporter: Dan Ellis
>Assignee: Dmitriy Pavlov
>Priority: Minor
>
> Log here: https://gist.github.com/danellis/660054b5a7f0e83ae4dcac8c1516d2ca
> It appears that the WAL path and the WAL archive path cannot be set to the 
> same directory. When they are, instead of the invalid configuration being 
> caught, a number of NPEs are thrown as shown in the above log.
> Additionally, this constraint does not appear to be documented.



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

[jira] [Updated] (IGNITE-7212) Load stoped after server node kill

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov updated IGNITE-7212:
-
Attachment: cfg_log_master_1.zip

> Load stoped after server node kill
> --
>
> Key: IGNITE-7212
> URL: https://issues.apache.org/jira/browse/IGNITE-7212
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Ilya Suntsov
>Priority: Critical
> Attachments: cfg_log_master_1.zip
>
>
> Scenario:
> * Start 4 servers
> * Start load tasks on 5 clients
> * Kill 1 server
> * Waiting for rebalancing
> * Kill 1 server
> Result:
> After the kill of second servers node load stoped.
> In servers logs I see messages like this:
> {noformat}
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Remote client 
> closed connection: GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
> [super=AbstractNioClientWorker [idx=0, bytesRcvd=130952565, 
> bytesSent=131203245, bytesRcvd0=3069200, bytesSent0=3068083, select=true, 
> super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null, 
> finished=false, hashCode=1748650517, interrupted=false, 
> runner=grid-nio-worker-tcp-comm-0-#41]]], 
> writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
> inRecovery=GridNioRecoveryDescriptor [acked=1024, resendCnt=0, rcvCnt=1026, 
> sentCnt=1029, reserved=true, lastAck=1024, nodeLeft=false, 
> node=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], outRecovery=GridNioRecoveryDescriptor 
> [acked=1024, resendCnt=0, rcvCnt=1026, sentCnt=1029, reserved=true, 
> lastAck=1024, nodeLeft=false, node=TcpDiscoveryNode 
> [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], connected=false, connectCnt=1, queueLimit=4096, 
> reserveCnt=1, pairedConnections=false], super=GridNioSessionImpl 
> [locAddr=/172.31.23.220:41732, 
> rmtAddr=ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47100, 
> createTime=1513335774008, closeTime=0, bytesSent=131203245, 
> bytesRcvd=130952565, bytesSent0=3068083, bytesRcvd0=3069200, 
> sndSchedTime=1513335774008, lastSndTime=1513337029027, 
> lastRcvTime=1513337029027, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter 
> [parser=org.apache.ignite.internal.util.nio.GridDirectParser@11ae7d3b, 
> directMode=true], GridConnectionBytesVerifyFilter], accepted=false]]
> [2017-12-15 11:23:50][WARN ][tcp-disco-msg-worker-#2] Failed to send message 
> to next node [msg=TcpDiscoveryConnectionCheckMessage 
> [super=TcpDiscoveryAbstractMessage [sndNodeId=null, 
> id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, verifierNodeId=null, 
> topVer=0, pendingIdx=0, failedNodes=null, isClient=false]], 
> next=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> addrs=[127.0.0.1, 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> isClient=false], errMsg=Failed to send message to next node 
> [msg=TcpDiscoveryConnectionCheckMessage [super=TcpDiscoveryAbstractMessage 
> [sndNodeId=null, id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, 
> verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, 
> isClient=false]], next=ClusterNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
> order=1, addr=[127.0.0.1, 172.31.20.3], daemon=false]]]
> [2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Session was 
> closed but there are unacknowledged messages, will try to reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Recovery reconnect 
> [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
> [2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Creating NIO client to node: 
> TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 
> 172.31.20.3], 
> sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
> 

[jira] [Created] (IGNITE-7212) Load stoped after server node kill

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-7212:


 Summary: Load stoped after server node kill
 Key: IGNITE-7212
 URL: https://issues.apache.org/jira/browse/IGNITE-7212
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Ilya Suntsov
Priority: Critical


Scenario:
* Start 4 servers
* Start load tasks on 5 clients
* Kill 1 server
* Waiting for rebalancing
* Kill 1 server
Result:
After the kill of second servers node load stoped.
In servers logs I see messages like this:
{noformat}
[2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Remote client 
closed connection: GridSelectorNioSessionImpl [worker=DirectNioClientWorker 
[super=AbstractNioClientWorker [idx=0, bytesRcvd=130952565, 
bytesSent=131203245, bytesRcvd0=3069200, bytesSent0=3068083, select=true, 
super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null, 
finished=false, hashCode=1748650517, interrupted=false, 
runner=grid-nio-worker-tcp-comm-0-#41]]], 
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
inRecovery=GridNioRecoveryDescriptor [acked=1024, resendCnt=0, rcvCnt=1026, 
sentCnt=1029, reserved=true, lastAck=1024, nodeLeft=false, 
node=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
addrs=[127.0.0.1, 172.31.20.3], 
sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
isClient=false], connected=false, connectCnt=1, queueLimit=4096, reserveCnt=1, 
pairedConnections=false], outRecovery=GridNioRecoveryDescriptor [acked=1024, 
resendCnt=0, rcvCnt=1026, sentCnt=1029, reserved=true, lastAck=1024, 
nodeLeft=false, node=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
addrs=[127.0.0.1, 172.31.20.3], 
sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
isClient=false], connected=false, connectCnt=1, queueLimit=4096, reserveCnt=1, 
pairedConnections=false], super=GridNioSessionImpl 
[locAddr=/172.31.23.220:41732, 
rmtAddr=ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47100, 
createTime=1513335774008, closeTime=0, bytesSent=131203245, 
bytesRcvd=130952565, bytesSent0=3068083, bytesRcvd0=3069200, 
sndSchedTime=1513335774008, lastSndTime=1513337029027, 
lastRcvTime=1513337029027, readsPaused=false, 
filterChain=FilterChain[filters=[GridNioCodecFilter 
[parser=org.apache.ignite.internal.util.nio.GridDirectParser@11ae7d3b, 
directMode=true], GridConnectionBytesVerifyFilter], accepted=false]]
[2017-12-15 11:23:50][WARN ][tcp-disco-msg-worker-#2] Failed to send message to 
next node [msg=TcpDiscoveryConnectionCheckMessage 
[super=TcpDiscoveryAbstractMessage [sndNodeId=null, 
id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, verifierNodeId=null, 
topVer=0, pendingIdx=0, failedNodes=null, isClient=false]], 
next=TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
addrs=[127.0.0.1, 172.31.20.3], 
sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
isClient=false], errMsg=Failed to send message to next node 
[msg=TcpDiscoveryConnectionCheckMessage [super=TcpDiscoveryAbstractMessage 
[sndNodeId=null, id=6c7f6d95061-c3cf9fe4-ab13-4d95-ace3-84a54cd73e08, 
verifierNodeId=null, topVer=0, pendingIdx=0, failedNodes=null, 
isClient=false]], next=ClusterNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
order=1, addr=[127.0.0.1, 172.31.20.3], daemon=false]]]
[2017-12-15 11:23:50][DEBUG][grid-nio-worker-tcp-comm-0-#41] Session was closed 
but there are unacknowledged messages, will try to reconnect 
[rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
[2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Recovery reconnect 
[rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d]
[2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Creating NIO client to node: 
TcpDiscoveryNode [id=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, addrs=[127.0.0.1, 
172.31.20.3], 
sockAddrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1513335739604, loc=false, ver=2.4.0#20171214-sha1:da782958, 
isClient=false]
[2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Addresses resolved from 
attributes [rmtNode=b7cfaa4e-b3b7-4485-a421-c731d9ed869d, 
addrs=[ip-172-31-20-3.us-east-2.compute.internal/172.31.20.3:47100, 
/127.0.0.1:47100], isRmtAddrsExist=true]
[2017-12-15 11:23:50][DEBUG][tcp-comm-worker-#1] Client creation failed 

[jira] [Commented] (IGNITE-5623) DDL needs to support DEFAULT operator

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5623:
-

Design considerations:
1) At this point we should support only constants, i.e. no functional stuff
2) Default values should be assigned from both SQL and cache operations 
3) May be it should not be applicable to key fields and affinity key fields 
(because in case of key-value access we would have wrong affinity). Need to 
investigate further. 

Looks like we need to hack mostly the same places as in IGNITE-5648. See commit 
*43be051* (12 Sep 2017).

> DDL needs to support DEFAULT operator 
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>  Labels: important
>
> There should be a way to set a default value for a column/field if the one is 
> not specified during an insert operation. In general, we need to support 
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
>   ID int,
>   FirstName varchar(255),
>   Age int,
>   City varchar(255) DEFAULT 'Sandnes'
> );
> {code}



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

[jira] [Assigned] (IGNITE-5580) Improve node failure cause information

[Vadim Opolski (JIRA)]

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

Vadim Opolski reassigned IGNITE-5580:
-

Assignee: (was: Vadim Opolski)

> Improve node failure cause information
> --
>
> Key: IGNITE-5580
> URL: https://issues.apache.org/jira/browse/IGNITE-5580
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>  Labels: observability
>
> When a node fails, we do not print out any information about the root cause 
> of this failure. This makes it extremely hard to investigate the failure 
> causes - I need to find a previous node for the failed node and check the 
> logs on the previous node.
> I suggest that we add extensive information about the reason of the node 
> failure and the sequence of events that led to this, e.g.:
> [time] [NODE] Sending a message to next node - failed _because_ - write 
> timeout, read timeout, ...?
> [time] [NODE] Connection check - failed - why? Connection refused, handshake 
> timed out, ...?
> ...
> [time] [NODE] Decided to drop the node because of the sequence above
> Maybe we do not need to print out this information always, but we do need 
> this when troubleshooting logger is enabled.
> Also, DiscoverySpi should collect a set of latest important events and dump 
> these events in case of local node segmentation. This will allow users to 
> match the events in the cluster and events on local node and get to the 
> bottom of the failure.



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

[jira] [Assigned] (IGNITE-5561) Warn about long-running cache store operations

[Vadim Opolski (JIRA)]

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

Vadim Opolski reassigned IGNITE-5561:
-

Assignee: (was: Vadim Opolski)

> Warn about long-running cache store operations
> --
>
> Key: IGNITE-5561
> URL: https://issues.apache.org/jira/browse/IGNITE-5561
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>  Labels: observability
>
> When a cache store is used, it may become very confusing if a cache store 
> performs a very long-running operation, because in this case, Ignite would 
> output a warning about long-running cache operations. I think, in addition to 
> that, we should measure and output a warning if a specific cache store 
> operation took too long.



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

[jira] [Assigned] (IGNITE-2049) Add to GridProductVersionSelfTest new tests for new naming strategy

[Vadim Opolski (JIRA)]

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

Vadim Opolski reassigned IGNITE-2049:
-

Assignee: (was: Vadim Opolski)

> Add to GridProductVersionSelfTest new tests for new naming strategy
> ---
>
> Key: IGNITE-2049
> URL: https://issues.apache.org/jira/browse/IGNITE-2049
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Alexey Kuznetsov
>Priority: Trivial
>  Labels: newbie
>
> See 
> http://apache-ignite-developers.2346864.n4.nabble.com/EA-versioning-td5381.html



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

[jira] [Closed] (IGNITE-7201) Web console: Auto check on leave of basic page

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin closed IGNITE-7201.
-

Will be fixed when IGNITE-5466 in master.

> Web console: Auto check on leave of basic page
> --
>
> Key: IGNITE-7201
> URL: https://issues.apache.org/jira/browse/IGNITE-7201
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.3
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>
> # Edit some cluster on basic screen.
> # Move to other page.
> Page is changed with loss of changes. Dialog to save changes is not shown.



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

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

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6625:
--

[~ptupitsyn], please assist with patching .NET. I have to add new members to 
the {{ClientConnectorConfiguration}}.
The .NET test fails:

{code}
 ClientConnectorConfigurationParityTest.TestConnectorConfiguration  

Test(s) failed. ClientConnectorConfiguration.isSslEnabled member is missing in 
.NET.
ClientConnectorConfiguration.isSslClientAuth member is missing in .NET.
ClientConnectorConfiguration.SslContextFactory member is missing in .NET.
{code}

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



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

[jira] [Assigned] (IGNITE-7201) Web console: Auto check on leave of basic page

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7201:
-

Assignee: Alexander Kalinin  (was: Pavel Konstantinov)

> Web console: Auto check on leave of basic page
> --
>
> Key: IGNITE-7201
> URL: https://issues.apache.org/jira/browse/IGNITE-7201
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.3
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>
> # Edit some cluster on basic screen.
> # Move to other page.
> Page is changed with loss of changes. Dialog to save changes is not shown.



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

[jira] [Commented] (IGNITE-5136) GridLogThrottle memory leak

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5136:


GitHub user SomeFire opened a pull request:

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

IGNITE-5136: GridLogThrottle memory leak



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

$ git pull https://github.com/SomeFire/ignite ignite-5136

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

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


commit 63bfe6a8681ea7a9f40de9d17f44df0c66c678ec
Author: vadopolski 
Date:   2017-09-05T17:29:58Z

Added test and cleanUpOldEntries

commit 30b132e7e2a62ae1d0605db1cdd107eb9ca1ec37
Author: vadopolski 
Date:   2017-09-05T18:19:27Z

Added check of timeStamp in map.

commit 09d0fed6fdc8ca910a5e1b67bbe4d3c1911a37d3
Author: vadopolski 
Date:   2017-09-05T19:28:59Z

Added testOnChangingTimeout

commit a13a6e78e9ecf1507cf2e82a0859fa10bf02babc
Author: vadopolski 
Date:   2017-09-06T14:12:04Z

Added lazy initialization.

commit eb75fe7d7219b3d1f9a2ba64d4a6fd532aee742d
Author: vadopolski 
Date:   2017-09-06T14:19:34Z

Added throttleTimeout.

commit 795593570e78623fea8c0d16f7c19423d6b83654
Author: vadopolski 
Date:   2017-09-06T14:23:42Z

Changed sleep timeout.

commit 18b8c75df9673d7c1223d66f74da68d436a45eee
Author: vadopolski 
Date:   2017-09-06T15:07:41Z

Added removing from errors with iterator.

commit 184f092b3bc0fd604480ae2cbd16f0fa8a7fed6e
Author: vadopolski 
Date:   2017-09-06T15:41:39Z

Code style.n

commit 881b78fd69ad1939bb580c49880623eb3ed74cca
Author: vadopolski 
Date:   2017-09-07T13:40:07Z

Improved iterator.

commit 90e9665f6371abbc3180c55ab75c714a38c1ed22
Author: vadopolski 
Date:   2017-09-07T16:24:34Z

Changed sleep timeout.

commit 6d2e0158bb5c0d8fc0c602cd0a8c874f0ed685e7
Author: vadopolski 
Date:   2017-09-07T16:37:13Z

Refactoring.

commit 9bfa9c3b60b53b1f444a6721f01dd84dc1f028f4
Author: vadopolski 
Date:   2017-09-07T16:47:31Z

Refactoring.

commit 0769ce86fdf5d73658548f31af21f9782d210f70
Author: vadopolski 
Date:   2017-09-07T16:50:36Z

Deleted loggedTs.

commit df05944a66448b4fcd3f635f8e348827096b5f15
Author: vadopolski 
Date:   2017-09-11T16:24:33Z

Review fixes

commit ec037cab659107d3f9959fe1b2540028f95d9345
Author: vadopolski 
Date:   2017-09-13T13:24:31Z

Added synchronized.

commit ec7d65527199039f84fcd4f0aa30cb1758c0e2e9
Author: vadopolski 
Date:   2017-09-13T17:46:39Z

Added cancel to synchronized area.

commit 2f8ba6b1864e479e934033fa7c49b44e1e57156e
Author: vadopolski 
Date:   2017-09-15T10:28:14Z

Added cancel to synchronized.

commit fabbc8bc22237f63e6a93851bdbbec7ee8bf5ec2
Author: vadopolski 
Date:   2017-09-15T13:31:46Z

Added cleanUpCancelEnabled to mapCleaningPeriodSetup.

commit ac850a5f6bf0cf44ea3afcd895a9ec95398834ca
Author: vadopolski 
Date:   2017-09-15T13:36:51Z

Refactoring.

commit 45c0eb6159bd51b23ed35ae7f49b6502c8c96ba8
Author: vadopolski 
Date:   2017-09-15T13:46:12Z

Overwritten mapCleaningPeriodSetup.

commit b2ec2a25de6fe484ac3dcfcd2b90256f2cf416bd
Author: vadopolski 
Date:   2017-09-15T14:11:31Z

Refactoring.

commit 3e11d19e1e39c3b476df65292640b83342455d19
Author: Dmitrii Ryabov 
Date:   2017-12-14T12:56:44Z

Merge branch 'master' into ignite-5136

commit c0be8de7de492122e35be641a9a0f06a1d4f937f
Author: Dmitrii Ryabov 
Date:   2017-12-14T15:33:44Z

IGNITE-5136: review fix.




> GridLogThrottle memory leak
> ---
>
> Key: IGNITE-5136
> URL: https://issues.apache.org/jira/browse/IGNITE-5136
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Stanilovsky Evgeny
>Assignee: Ryabov Dmitrii
> Fix For: 2.4
>
>
> class GridLogThrottle stores throttle info into map and noone clears it.



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

[jira] [Assigned] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev reassigned IGNITE-7196:
---

Assignee: Ilya Kasnacheev

> Exchange can stuck and wait while new node restoring state from disk and 
> starting caches
> 
>
> Key: IGNITE-7196
> URL: https://issues.apache.org/jira/browse/IGNITE-7196
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.4
>
>
> Exchange can stuck and wait while new node restoring state from disk and 
> starting caches, there's a log snippet from a just joined new node that shows 
> the issue:
> [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started 
> exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], 
> crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, 
> customEvt=null, allowMerge=true]
> [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager]
>  Resolved page store work directory: 
> /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
>  Resolved write ahead log work directory: 
> /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
>  Resolved write ahead log archive directory: 
> /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
> [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
>  Started write-ahead log manager [mode=DEFAULT]
> [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] 
> Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 
> KiB, checkpointBuffer=100.0 MiB]
> [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] 
> Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 
> MiB, checkpointBuffer=896.0 MiB]
> [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
>  Read checkpoint status 
> [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin,
>  
> endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin]
> [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
>  Checking memory state [lastValidPos=FileWALPointer [idx=3582, 
> fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer 
> [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], 
> lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af]
> [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
>  Ignite node stopped in the middle of checkpoint. Will restore memory state 
> and finish checkpoint on node start.
> [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/172.31.20.209:48100, 
> rmtAddr=/172.31.17.115:57148]
> [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
>  Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, 
> pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, 
> forceFlush=false]]
> [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
>  Finished applying memory changes [changesApplied=165103, time=8189ms]
> [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/172.31.20.209:48100, 
> rmtAddr=/172.31.28.10:47964]
> [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi]
>  Accepted incoming communication connection [locAddr=/172.31.20.209:48100, 
> rmtAddr=/172.31.27.101:46000]
> [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to 
> wait for initial partition map exchange. Possible reasons are:
> ^-- Transactions in deadlock.
> ^-- Long running transactions (ignore if this is the case).
> ^-- Unreleased explicit locks.
> [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still 
> waiting for initial partition map exchange 
> [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, 
> addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], 
> sockAddrs=[/0:0:0:0:0:0:0:1%lo:48500, /127.0.0.1:48500, 
> 

[jira] [Assigned] (IGNITE-5136) GridLogThrottle memory leak

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii reassigned IGNITE-5136:
--

Assignee: Ryabov Dmitrii  (was: Vadim Opolski)

> GridLogThrottle memory leak
> ---
>
> Key: IGNITE-5136
> URL: https://issues.apache.org/jira/browse/IGNITE-5136
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Stanilovsky Evgeny
>Assignee: Ryabov Dmitrii
>
> class GridLogThrottle stores throttle info into map and noone clears it.



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

[jira] [Comment Edited] (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:comment-tabpanel=16292167#comment-16292167
 ] 

Roman Kondakov edited comment on IGNITE-7039 at 12/15/17 9:20 AM:
--

[~vozerov], please review.
1) In {{IgniteH2Indexing.queryLocalSqlFields}} I implemented an eager 
partitions reservation on {{IgniteCache.query()}} call. I also implemented a 
test {{IgniteCacheLocalQueryReservationsTest}} for checking a partitions 
reservation status on each stage:
*  Before {{IgniteCache.query()}}.
*  After {{IgniteCache.query()}}.
*  After {{QueryCursor.iterator()}}.
*  After {{Iterator.next()}}.
*  After {{QueryCursor.close()}}.

2) I implemented another method for a gathering all caches ids used in a query 
based on {{GridSqlQueryParser}}. I also added a cache map for the parsed 
queries.


was (Author: rkondakov):
[~vozerov], please review.
1) In {{IgniteH2Indexing.queryLocalSqlFields}} I implemented an eager 
partitions reservation on {{IgniteCache.query()}} call. I also implemented a 
test {{IgniteCacheLocalQueryReservationsTest}} for checking a partitions 
reservation status on each stage:
*  Before {{IgniteCache.query()}}.
*  After {{IgniteCache.query()}}.
*  After {{QueryCursor.iterator()}}.
*  After {{Iterator.next()}}.
*  After {{QueryCursor.close()}}.

2. I implemented another method for a gathering all caches ids used in a query 
based on {{GridSqlQueryParser}}. I also added a cache map for the parsed 
queries.

> 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
> Fix For: 2.4
>
>
> 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-6736) Java 9: rework GridCacheMapEntry synchronization logic to avoid Unsafe.monitor* methods

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6736:


Assignee: Andrey Kuznetsov

> Java 9: rework GridCacheMapEntry synchronization logic to avoid 
> Unsafe.monitor* methods
> ---
>
> Key: IGNITE-6736
> URL: https://issues.apache.org/jira/browse/IGNITE-6736
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> {{GridCacheMapEntry}} class rely on {{synchronized}} on itself heavily. In 
> {{ATOMIC}} caches we lock multiple entries at once using 
> {{Unsafe.monitorEnter/Exit}} methods. Unfortunately these methods were 
> removed in Java 9. Recursion is not an option, as it would cause stack 
> overflow for {{putAll}} operations with multiple entries.
> Possible fixes:
> 1) Rework {{synchronized}} to {{ReentrantLock}}. Easy, but may cause 
> additional memory pressure.
> 2) Have different implementations for Java 8 ({{synchronzied}}) and Java 9 
> ({{ReentrantLock}}) - much more complex solution, because we will require 
> separate module for Java 8 and Java 9.
> 3) Rework {{ATOMIC}} caches, so that {{putAll}} operation updates entries 
> one-by-one. As a side effect it will eliminate deadlocks.



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

[jira] [Assigned] (IGNITE-7031) Web console: Error on cancellation of comfirm dialog

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7031:
-

Assignee: Alexander Kalinin  (was: Alexey Kuznetsov)

> Web console: Error on cancellation of comfirm dialog
> 
>
> Key: IGNITE-7031
> URL: https://issues.apache.org/jira/browse/IGNITE-7031
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>
> On cancellation of confirm dialog error message showed in log of browser.
> F.e. Clone dialog or remove all dialog.



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

[jira] [Assigned] (IGNITE-7034) Web console: Hide connected clusters label on "become this user"

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7034:
-

Assignee: Alexander Kalinin  (was: Alexey Kuznetsov)

> Web console: Hide connected clusters label on "become this user"
> 
>
> Key: IGNITE-7034
> URL: https://issues.apache.org/jira/browse/IGNITE-7034
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>




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

[jira] [Updated] (IGNITE-7034) Web console: Hide connected clusters label on "become this user"

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-7034:
--
Description: (was: On become this user first time showed lint of admin 
notebooks. That notebooks is not available.
On refresh show notebooks of showed user.)

> Web console: Hide connected clusters label on "become this user"
> 
>
> Key: IGNITE-7034
> URL: https://issues.apache.org/jira/browse/IGNITE-7034
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>




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

[jira] [Updated] (IGNITE-7034) Web console: Hide connected clusters label on "become this user"

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-7034:
--
Summary: Web console: Hide connected clusters label on "become this user"  
(was: Web console: Wrong notebooks on become this user)

> Web console: Hide connected clusters label on "become this user"
> 
>
> Key: IGNITE-7034
> URL: https://issues.apache.org/jira/browse/IGNITE-7034
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> On become this user first time showed lint of admin notebooks. That notebooks 
> is not available.
> On refresh show notebooks of showed user.



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

[jira] [Commented] (IGNITE-6736) Java 9: rework GridCacheMapEntry synchronization logic to avoid Unsafe.monitor* methods

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6736:
--

Choosing ReentrantLock approach. See [1].

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Separate-code-paths-for-Java-8-and-Java-9-tp25289p25291.html

> Java 9: rework GridCacheMapEntry synchronization logic to avoid 
> Unsafe.monitor* methods
> ---
>
> Key: IGNITE-6736
> URL: https://issues.apache.org/jira/browse/IGNITE-6736
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
> Fix For: 2.4
>
>
> {{GridCacheMapEntry}} class rely on {{synchronized}} on itself heavily. In 
> {{ATOMIC}} caches we lock multiple entries at once using 
> {{Unsafe.monitorEnter/Exit}} methods. Unfortunately these methods were 
> removed in Java 9. Recursion is not an option, as it would cause stack 
> overflow for {{putAll}} operations with multiple entries.
> Possible fixes:
> 1) Rework {{synchronized}} to {{ReentrantLock}}. Easy, but may cause 
> additional memory pressure.
> 2) Have different implementations for Java 8 ({{synchronzied}}) and Java 9 
> ({{ReentrantLock}}) - much more complex solution, because we will require 
> separate module for Java 8 and Java 9.
> 3) Rework {{ATOMIC}} caches, so that {{putAll}} operation updates entries 
> one-by-one. As a side effect it will eliminate deadlocks.



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

[jira] [Assigned] (IGNITE-7035) Web console: New user redirected on nonexistent page

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7035:
-

Assignee: Alexey Kuznetsov

> Web console: New user redirected on nonexistent page
> 
>
> Key: IGNITE-7035
> URL: https://issues.apache.org/jira/browse/IGNITE-7035
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> New user redirected on login to /configuration page and then redirected to 
> /configuration/basic.
> Should be redirected directly to /configuration/basic.



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

[jira] [Assigned] (IGNITE-7037) Web console: Wrong activities metrics

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7037:
-

Assignee: Alexey Kuznetsov

> Web console: Wrong activities metrics
> -
>
> Key: IGNITE-7037
> URL: https://issues.apache.org/jira/browse/IGNITE-7037
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> Count of activity metrics in grouped columns is not calculated from detail 
> columns.
> Configuration's activities columns show always 0.
> Showed data in table is not equal to data from activity dialog.



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

[jira] [Assigned] (IGNITE-7034) Web console: Wrong notebooks on become this user

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7034:
-

Assignee: Alexey Kuznetsov

> Web console: Wrong notebooks on become this user
> 
>
> Key: IGNITE-7034
> URL: https://issues.apache.org/jira/browse/IGNITE-7034
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> On become this user first time showed lint of admin notebooks. That notebooks 
> is not available.
> On refresh show notebooks of showed user.



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

[jira] [Assigned] (IGNITE-7032) Web console: Links in activiy details.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7032:
-

Assignee: Alexey Kuznetsov

> Web console: Links in activiy details.
> --
>
> Key: IGNITE-7032
> URL: https://issues.apache.org/jira/browse/IGNITE-7032
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> In activity details dialog of admin page should be showed page title instead 
> of its link.



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

[jira] [Assigned] (IGNITE-7031) Web console: Error on cancellation of comfirm dialog

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7031:
-

Assignee: Alexey Kuznetsov

> Web console: Error on cancellation of comfirm dialog
> 
>
> Key: IGNITE-7031
> URL: https://issues.apache.org/jira/browse/IGNITE-7031
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> On cancellation of confirm dialog error message showed in log of browser.
> F.e. Clone dialog or remove all dialog.



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

[jira] [Assigned] (IGNITE-7033) Web console: Increase width of columns on admin page

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7033:
-

Assignee: Alexey Kuznetsov

> Web console: Increase width of columns on admin page
> 
>
> Key: IGNITE-7033
> URL: https://issues.apache.org/jira/browse/IGNITE-7033
> Project: Ignite
>  Issue Type: Bug
> Environment: "Last activity" and "email" columns are too narrow
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>




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

[jira] [Assigned] (IGNITE-7030) Web console: (add) link not create new linked item

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7030:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Web console: (add) link not create new linked item
> --
>
> Key: IGNITE-7030
> URL: https://issues.apache.org/jira/browse/IGNITE-7030
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> On click by (add) link on configuration pages opened page with list of 
> objects instead of creation of new with link to current.



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

[jira] [Assigned] (IGNITE-7030) Web console: (add) link not create new linked item

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7030:
-

Assignee: Vasiliy Sisko

> Web console: (add) link not create new linked item
> --
>
> Key: IGNITE-7030
> URL: https://issues.apache.org/jira/browse/IGNITE-7030
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>
> On click by (add) link on configuration pages opened page with list of 
> objects instead of creation of new with link to current.



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

[jira] [Assigned] (IGNITE-7201) Web console: Auto check on leave of basic page

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7201:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

Added dialog with preventing unsaved changes. Please test.

> Web console: Auto check on leave of basic page
> --
>
> Key: IGNITE-7201
> URL: https://issues.apache.org/jira/browse/IGNITE-7201
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.3
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>
> # Edit some cluster on basic screen.
> # Move to other page.
> Page is changed with loss of changes. Dialog to save changes is not shown.



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

[jira] [Comment Edited] (IGNITE-7167) Optimize 'select count(*) from Table'

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-7167 at 12/15/17 8:43 AM:
---

We already optimized this, see IGNITE-6702. We cannot get rid of scan in 
general case. For now we iterate over index entries and count them. This is the 
best what can be done. 
However, when MVCC is ready, we will have to resort to (almost) original 
approach - for every entry in the index we would have to check whether it is 
visible.


was (Author: vozerov):
We already optimized this, see IGNITE-6702. We cannot get rid of scan in 
general case. For now we iterate over index entries and count them. This is the 
best what can be done. 

However, when MVCC is ready, we will have to resort to (almost) original 
approach - for every entry in the index we would have to check whether it is 
visible.

> Optimize 'select count(*) from Table'
> -
>
> Key: IGNITE-7167
> URL: https://issues.apache.org/jira/browse/IGNITE-7167
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>
> Currently query like {{select count(*) from Table}} effectively scans the 
> cache and take a lot of time for large datasets. Probably makes sense to 
> optimize it to use {{IgniteCache#size}} directly when possible.



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

[jira] [Closed] (IGNITE-7167) Optimize 'select count(*) from Table'

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-7167.
---

> Optimize 'select count(*) from Table'
> -
>
> Key: IGNITE-7167
> URL: https://issues.apache.org/jira/browse/IGNITE-7167
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>
> Currently query like {{select count(*) from Table}} effectively scans the 
> cache and take a lot of time for large datasets. Probably makes sense to 
> optimize it to use {{IgniteCache#size}} directly when possible.



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

[jira] [Resolved] (IGNITE-7167) Optimize 'select count(*) from Table'

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-7167.
-
Resolution: Duplicate

We already optimized this, see IGNITE-6702. We cannot get rid of scan in 
general case. For now we iterate over index entries and count them. This is the 
best what can be done. 

However, when MVCC is ready, we will have to resort to (almost) original 
approach - for every entry in the index we would have to check whether it is 
visible.

> Optimize 'select count(*) from Table'
> -
>
> Key: IGNITE-7167
> URL: https://issues.apache.org/jira/browse/IGNITE-7167
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>
> Currently query like {{select count(*) from Table}} effectively scans the 
> cache and take a lot of time for large datasets. Probably makes sense to 
> optimize it to use {{IgniteCache#size}} directly when possible.



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

[jira] [Updated] (IGNITE-7211) Web console: Wrong cluster active state on cluster switch.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-7211:
--
Attachment: ignite-7211.png

> Web console: Wrong cluster active state on cluster switch.
> --
>
> Key: IGNITE-7211
> URL: https://issues.apache.org/jira/browse/IGNITE-7211
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Attachments: ignite-7211.png
>
>
> # Connect two inactive clusters to Web console.
> # Switch cluster in time of some cluster activation.
> Active state showed for both clusters as active and do not changed on next 
> cluster switch.



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

[jira] [Created] (IGNITE-7211) Web console: Wrong cluster active state on cluster switch.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-7211:
-

 Summary: Web console: Wrong cluster active state on cluster switch.
 Key: IGNITE-7211
 URL: https://issues.apache.org/jira/browse/IGNITE-7211
 Project: Ignite
  Issue Type: Bug
Reporter: Vasiliy Sisko
Assignee: Alexey Kuznetsov


# Connect two inactive clusters to Web console.
# Switch cluster in time of some cluster activation.
Active state showed for both clusters as active and do not changed on next 
cluster switch.



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

[jira] [Created] (IGNITE-7210) Web console: Fix show time of "Connected clusters: N" label

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-7210:
-

 Summary: Web console: Fix show time of "Connected clusters: N" 
label
 Key: IGNITE-7210
 URL: https://issues.apache.org/jira/browse/IGNITE-7210
 Project: Ignite
  Issue Type: Bug
  Components: website
Reporter: Vasiliy Sisko
Assignee: Alexey Kuznetsov


Now that label showed quickly when login screen still shown or page is fully 
empty.
Should appear together with page content.



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

[jira] [Closed] (IGNITE-7199) Web Console: some improvments

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-7199.


> Web Console: some improvments
> -
>
> Key: IGNITE-7199
> URL: https://issues.apache.org/jira/browse/IGNITE-7199
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> 1. Add registered date.
> 2. Improve becomed mode (hide non supported in this mode features).
> 3. Improved export from grids.



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

[jira] [Updated] (IGNITE-7199) Web Console: some improvments

[Alexey Kuznetsov (JIRA)]

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

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

> Web Console: some improvments
> -
>
> Key: IGNITE-7199
> URL: https://issues.apache.org/jira/browse/IGNITE-7199
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> 1. Add registered date.
> 2. Improve becomed mode (hide non supported in this mode features).
> 3. Improved export from grids.



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

[jira] [Commented] (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:comment-tabpanel=16292167#comment-16292167
 ] 

Roman Kondakov commented on IGNITE-7039:


[~vozerov], please review.
1) In {{IgniteH2Indexing.queryLocalSqlFields}} I implemented an eager 
partitions reservation on {{IgniteCache.query()}} call. I also implemented a 
test {{IgniteCacheLocalQueryReservationsTest}} for checking a partitions 
reservation status on each stage:
*  Before {{IgniteCache.query()}}.
*  After {{IgniteCache.query()}}.
*  After {{QueryCursor.iterator()}}.
*  After {{Iterator.next()}}.
*  After {{QueryCursor.close()}}.

2. I implemented another method for a gathering all caches ids used in a query 
based on {{GridSqlQueryParser}}. I also added a cache map for the parsed 
queries.

> 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
> Fix For: 2.4
>
>
> 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)