[jira] [Commented] (IGNITE-6916) A node joining with enabled persistence and empty disc space causes exchange to hang.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6916:


Github user asfgit closed the pull request at:

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


> A node joining with enabled persistence and empty disc space causes exchange 
> to hang.
> -
>
> Key: IGNITE-6916
> URL: https://issues.apache.org/jira/browse/IGNITE-6916
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Stanilovsky Evgeny
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> If no more free disk space occurs, while node joining cluster, it will be 
> hanging.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6983:

Labels: iep-1  (was: )

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



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

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

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6983:
---

 Summary: SQL: optimize CREATE INDEX and BPlusTree interaction
 Key: IGNITE-6983
 URL: https://issues.apache.org/jira/browse/IGNITE-6983
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Reporter: Vladimir Ozerov
 Fix For: 2.4


Currently index is built as follows:
1) Get next entry from partition's tree
2) Read it's key (copy to heap)
3) Acquire lock on {{GridCacheMapEntry}}
4) Lookup the same key in the tree from the top
5) Read it's value (copy to heap)
6) Add to index.

This is very complex flow. We can optimize two things - tree lookup and value 
deserialization as follows:
1) Every data page will have update counter, which is incremented every time 
anything is changed.
2) When lock on {{GridCacheMapEntry}} is acquired, we will acquire lock on the 
data page and re-check update counter. 
3) If page was changed between iterator read and lock acquisition then use old 
flow. 
4) Otherwise - set read lock on the page, read value as *offheap* object, apply 
it to index.



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

[jira] [Commented] (IGNITE-6955) Update com.google.code.simple-spring-memcached:spymemcached to 2.8.4

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-6955:
--

Anton, thanks:
1. done
2. done

> Update com.google.code.simple-spring-memcached:spymemcached to 2.8.4
> 
>
> Key: IGNITE-6955
> URL: https://issues.apache.org/jira/browse/IGNITE-6955
> Project: Ignite
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Minor
> Fix For: 2.4
>
>
> Please update com.google.code.simple-spring-memcached:spymemcached to 2.8.4 
> version.
> This version does not have "netty" dependencies



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

[jira] [Assigned] (IGNITE-6919) Web console: incorrect character in tab name under IE11

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-6919:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

Fixed symbol rendering.

> Web console: incorrect character in tab name under IE11
> ---
>
> Key: IGNITE-6919
> URL: https://issues.apache.org/jira/browse/IGNITE-6919
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Trivial
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> !screenshot-1.png!



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

[jira] [Resolved] (IGNITE-6982) .NET: Migrate to latest NUnit

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-6982.

Resolution: Won't Fix

> .NET: Migrate to latest NUnit
> -
>
> Key: IGNITE-6982
> URL: https://issues.apache.org/jira/browse/IGNITE-6982
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> We use very old NUnit 2.6. In order to reuse tests under .NET Core 
> (IGNITE-2662) we need latest NUnit.



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

[jira] [Commented] (IGNITE-6982) .NET: Migrate to latest NUnit

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6982:


Turns out NUnit 3 does not propagate console output to the test runner window 
properly. This is a big issue, let's stay under 2.6.

> .NET: Migrate to latest NUnit
> -
>
> Key: IGNITE-6982
> URL: https://issues.apache.org/jira/browse/IGNITE-6982
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> We use very old NUnit 2.6. In order to reuse tests under .NET Core 
> (IGNITE-2662) we need latest NUnit.



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

[jira] [Comment Edited] (IGNITE-2662) .NET Core support (run on Linux)

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-2662 at 11/21/17 5:58 PM:
--

We can't reuse all tests (since some things are .NET-specific and 
Windows-specific, like AppDomain stuff), but we can reuse some tests by using 
"Add as link" project feature. However, latest NUnit is required to run under 
.NET Core. Ticket filed: IGNITE-6982.

Also many tests use internals a lot. See if {{[InternalsVisibleTo]}} can be 
used for .NET Core assembly.


was (Author: ptupitsyn):
We can't reuse all tests (since some things are .NET-specific and 
Windows-specific, like AppDomain stuff), but we can reuse some tests by using 
"Add as link" project feature. However, latest NUnit is required to run under 
.NET Core. Ticket filed: IGNITE-6982.

> .NET Core support (run on Linux)
> 
>
> Key: IGNITE-2662
> URL: https://issues.apache.org/jira/browse/IGNITE-2662
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, xplat
> Fix For: 2.4
>
>
> Ignite.NET should target .NET Standard so it is available on maximum number 
> of platforms, see
> https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
> https://weblog.west-wind.com/posts/2016/Nov/23/NET-Standard-20-Making-Sense-of-NET-Again
> https://github.com/dotnet/core/blob/master/roadmap.md
> Make sure that all used APIs are supported on all platforms, see API Analyzer 
> tool:
> https://channel9.msdn.com/coding4fun/blog/Your-New-Virtual-API-Review-Assistant
> This will allow us to run on Windows, OSX, and Linux, and target .NET Core in 
> additional to good old regular .NET.
> Possible difficulties:
> * JNI interop. Core has dllImport and it works on linux, and our C++ client 
> works on linux, so it should be possible
> * Reflection. We use it a lot, and API has changed.



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

[jira] [Commented] (IGNITE-2662) .NET Core support (run on Linux)

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2662:


We can't reuse all tests (since some things are .NET-specific and 
Windows-specific, like AppDomain stuff), but we can reuse some tests by using 
"Add as link" project feature. However, latest NUnit is required to run under 
.NET Core. Ticket filed: IGNITE-6982.

> .NET Core support (run on Linux)
> 
>
> Key: IGNITE-2662
> URL: https://issues.apache.org/jira/browse/IGNITE-2662
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, xplat
> Fix For: 2.4
>
>
> Ignite.NET should target .NET Standard so it is available on maximum number 
> of platforms, see
> https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
> https://weblog.west-wind.com/posts/2016/Nov/23/NET-Standard-20-Making-Sense-of-NET-Again
> https://github.com/dotnet/core/blob/master/roadmap.md
> Make sure that all used APIs are supported on all platforms, see API Analyzer 
> tool:
> https://channel9.msdn.com/coding4fun/blog/Your-New-Virtual-API-Review-Assistant
> This will allow us to run on Windows, OSX, and Linux, and target .NET Core in 
> additional to good old regular .NET.
> Possible difficulties:
> * JNI interop. Core has dllImport and it works on linux, and our C++ client 
> works on linux, so it should be possible
> * Reflection. We use it a lot, and API has changed.



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

[jira] [Created] (IGNITE-6982) .NET: Migrate to latest NUnit

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6982:
--

 Summary: .NET: Migrate to latest NUnit
 Key: IGNITE-6982
 URL: https://issues.apache.org/jira/browse/IGNITE-6982
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.4


We use very old NUnit 2.6. In order to reuse tests under .NET Core 
(IGNITE-2662) we need latest NUnit.



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5874:


We also need to add compatibility test for TTL caches into Ignite Compatibility 
suite.

Probably we should also create automatic migration or migration tool for cache 
page store with TTL enabled.

See related discussion in 
http://apache-ignite-developers.2346864.n4.nabble.com/Data-eviction-expiration-from-Ignite-persistence-td24419.html

> 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
> 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] [Updated] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3495:

Labels: iep-6  (was: )

> CacheMetrics.getAverage###Time is not calculated properly
> -
>
> Key: IGNITE-3495
> URL: https://issues.apache.org/jira/browse/IGNITE-3495
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Vyacheslav Koptilin
>  Labels: iep-6
> Attachments: ExampleNodeStartupClient.java, IGNITE_3495.patch, 
> example-default.xml
>
>
> {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and 
> {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the 
> following scenario:
> - start a server node;
> - start a client node that will perform gets and puts;
> - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's 
> cluster group.
> The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not 
> called on the server side when a metric related event happens.
> In the attache you can find source that showcases the bug.
> - start basic {{ExampleNodeStartup}} using attached configuration 
> {{example-default.xml}} conjuration;
> - start {{ExampleNodeStartupClient}}. You will see that average metrics are 
> not incremented.



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

[jira] [Updated] (IGNITE-6981) System thread pool continuously creates and destroys threads while idle

[Joel Lang (JIRA)]

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

Joel Lang updated IGNITE-6981:
--
Description: 
I've observed using VisualVM that Ignite is continuously starting and stopping 
system pool threads even while the pool is idle.

I've attached a screenshot. Notice the high thread number on the left.

!threads.jpg|thumbnail!

  was:
I've observed using VisualVM that Ignite is continuously starting and stopping 
system pool threads even while the pool is idle.

I've attached a screenshot. Notice the high thread number on the left.


> System thread pool continuously creates and destroys threads while idle
> ---
>
> Key: IGNITE-6981
> URL: https://issues.apache.org/jira/browse/IGNITE-6981
> Project: Ignite
>  Issue Type: Bug
>  Components: 2.3, general
>Affects Versions: 2.3
>Reporter: Joel Lang
>Priority: Minor
> Attachments: threads.jpg
>
>
> I've observed using VisualVM that Ignite is continuously starting and 
> stopping system pool threads even while the pool is idle.
> I've attached a screenshot. Notice the high thread number on the left.
> !threads.jpg|thumbnail!



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

[jira] [Updated] (IGNITE-6981) System thread pool continuously creates and destroys threads while idle

[Joel Lang (JIRA)]

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

Joel Lang updated IGNITE-6981:
--
Description: 
I've observed using VisualVM that Ignite is continuously starting and stopping 
system pool threads even while the pool is idle.

I've attached a screenshot. Notice the high thread number on the left.

  was:
I've observed using VisualVM that Ignite is continuously starting and stopping 
system pool threads even while the pool is idle.

I've attached a screenshot. Notice the high thread number on the left.

!threads.jpg|thumbnail!


> System thread pool continuously creates and destroys threads while idle
> ---
>
> Key: IGNITE-6981
> URL: https://issues.apache.org/jira/browse/IGNITE-6981
> Project: Ignite
>  Issue Type: Bug
>  Components: 2.3, general
>Affects Versions: 2.3
>Reporter: Joel Lang
>Priority: Minor
> Attachments: threads.jpg
>
>
> I've observed using VisualVM that Ignite is continuously starting and 
> stopping system pool threads even while the pool is idle.
> I've attached a screenshot. Notice the high thread number on the left.



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

[jira] [Updated] (IGNITE-6981) System thread pool continuously creates and destroys threads while idle

[Joel Lang (JIRA)]

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

Joel Lang updated IGNITE-6981:
--
Attachment: threads.jpg

> System thread pool continuously creates and destroys threads while idle
> ---
>
> Key: IGNITE-6981
> URL: https://issues.apache.org/jira/browse/IGNITE-6981
> Project: Ignite
>  Issue Type: Bug
>  Components: 2.3, general
>Affects Versions: 2.3
>Reporter: Joel Lang
>Priority: Minor
> Attachments: threads.jpg
>
>
> I've observed using VisualVM that Ignite is continuously starting and 
> stopping system pool threads even while the pool is idle.
> I've attached a screenshot. Notice the high thread number on the left.



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

[jira] [Created] (IGNITE-6981) System thread pool continuously creates and destroys threads while idle

[Joel Lang (JIRA)]

Joel Lang created IGNITE-6981:
-

 Summary: System thread pool continuously creates and destroys 
threads while idle
 Key: IGNITE-6981
 URL: https://issues.apache.org/jira/browse/IGNITE-6981
 Project: Ignite
  Issue Type: Bug
  Components: 2.3, general
Affects Versions: 2.3
Reporter: Joel Lang
Priority: Minor


I've observed using VisualVM that Ignite is continuously starting and stopping 
system pool threads even while the pool is idle.

I've attached a screenshot. Notice the high thread number on the left.



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

[jira] [Updated] (IGNITE-6814) Detailed memory consumption on start and OOM reporting

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6814:

Priority: Blocker  (was: Critical)

> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Blocker
>  Labels: iep-6, usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user 
> doesn't see automatically chosen memory settings. Also, if there a node runs 
> out of RAM and throws an OOM error there are no hints on why this happened 
> and how to fix it.
> Suggestions: 
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will 
> accumulate maximum size of all the data regions defined cluster-wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N}, 
> heap=1.8GB, ]
> {code}
> * Print detailed memory configuration below {{Topology Snapshot}} message 
> following this format:
> {code}
> Data Regions Configured:
> ^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
> {code}
> Example:
> {code}
> Data Regions Configured:
>^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
>^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB, 
> persistenceEnabled=false]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data 
> region name with all its current parameters and suggest three possible things 
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> {code}
> Out of memory in data region Region_Name [initSize=N, maxSize=N, 
> persistenceEnabled={true|false}]. Do one of the following:
>^-- Increase maximum size (DataRegionConfiguration.maxSize)
>^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled) 
> or
>^-- Enable eviction or expiration policies.
> {code}



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

[jira] [Updated] (IGNITE-6814) Detailed memory consumption on start and OOM reporting

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6814:

Labels: iep-6 usability  (was: usability)

> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Critical
>  Labels: iep-6, usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user 
> doesn't see automatically chosen memory settings. Also, if there a node runs 
> out of RAM and throws an OOM error there are no hints on why this happened 
> and how to fix it.
> Suggestions: 
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will 
> accumulate maximum size of all the data regions defined cluster-wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N}, 
> heap=1.8GB, ]
> {code}
> * Print detailed memory configuration below {{Topology Snapshot}} message 
> following this format:
> {code}
> Data Regions Configured:
> ^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
> {code}
> Example:
> {code}
> Data Regions Configured:
>^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
>^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB, 
> persistenceEnabled=false]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data 
> region name with all its current parameters and suggest three possible things 
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> {code}
> Out of memory in data region Region_Name [initSize=N, maxSize=N, 
> persistenceEnabled={true|false}]. Do one of the following:
>^-- Increase maximum size (DataRegionConfiguration.maxSize)
>^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled) 
> or
>^-- Enable eviction or expiration policies.
> {code}



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

[jira] [Created] (IGNITE-6980) Automatic cancelling of hanging Ignite operations

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6980:
---

 Summary: Automatic cancelling of hanging Ignite operations
 Key: IGNITE-6980
 URL: https://issues.apache.org/jira/browse/IGNITE-6980
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
Priority: Critical
 Fix For: 2.4


If an Ignite operation hangs due to some reason due to an internal problem or 
buggy application code it needs to eventual fail after a timeout fires.

Take atomic operations case brought by Val to our attention recently:
http://apache-ignite-developers.2346864.n4.nabble.com/Timeouts-in-atomic-cache-td19839.html

An application must not freeze waiting for a human being intervention if an 
atomic update fails internally.

Even more, I would let all possible operation to fail after a timeout fires:
- Ignite compute computations.
- Ignite services calls.
- Atomic/transactional cache updates.
- SQL queries.



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

[jira] [Updated] (IGNITE-6979) Race in GridClientPartitionTopology may cause NPE and partition map exchange hang.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-6979:
--
Description: 
Was reproduced on TC and locally using test
{{org.apache.ignite.internal.processors.cache.IgniteCachePartitionMapUpdateTest#testRandom}}

Reason: discoCache is not initalized due to race before calling  
{{GridClientPartitionTopology#nodes(int, AffinityTopologyVersion, 
GridDhtPartitionState, GridDhtPartitionState...)}}

Stacktrace on coordinator:

{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.nodes(GridClientPartitionTopology.java:538)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:577)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:582)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2117)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllRegisteredCacheGroups(CacheAffinitySharedManager.java:1059)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initAffinityOnNodeLeft0(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onServerLeftWithExchangeMergeProtocol(CacheAffinitySharedManager.java:1383)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2239)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2199)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1936)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1793)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1483)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:307)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2626)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2605)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1562)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1190)
at 

[jira] [Updated] (IGNITE-6979) Race in GridClientPartitionTopology may cause NPE and partition map exchange hang.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-6979:
--
Description: 
Was reproduced on TC and locally using test
{{org.apache.ignite.internal.processors.cache.IgniteCachePartitionMapUpdateTest#testRandom}}

Reason: discoCache is not initalized before calling  
{{GridClientPartitionTopology#nodes(int, AffinityTopologyVersion, 
GridDhtPartitionState, GridDhtPartitionState...)}}

Stacktrace on coordinator:

{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.nodes(GridClientPartitionTopology.java:538)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:577)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:582)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2117)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllRegisteredCacheGroups(CacheAffinitySharedManager.java:1059)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initAffinityOnNodeLeft0(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onServerLeftWithExchangeMergeProtocol(CacheAffinitySharedManager.java:1383)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2239)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2199)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1936)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1793)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1483)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:307)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2626)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2605)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1562)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1190)
at 

[jira] [Updated] (IGNITE-6979) Race in GridClientPartitionTopology may cause NPE and partition map exchange hang.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-6979:
--
Description: 
Was reproduced on TC and locally using test
{{org.apache.ignite.internal.processors.cache.IgniteCachePartitionMapUpdateTest#testRandom}}

Reason: discoCache is not initalized before calling  
{{GridClientPartitionTopology#nodes(int, AffinityTopologyVersion, 
GridDhtPartitionState, GridDhtPartitionState...)}}

Stacktrace on coordinator:

{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.nodes(GridClientPartitionTopology.java:538)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:577)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:582)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2117)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllRegisteredCacheGroups(CacheAffinitySharedManager.java:1059)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initAffinityOnNodeLeft0(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onServerLeftWithExchangeMergeProtocol(CacheAffinitySharedManager.java:1383)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2239)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2199)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1936)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1793)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1483)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:307)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2626)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2605)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1562)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1190)
at 

[jira] [Updated] (IGNITE-6979) Race in GridClientPartitionTopology may cause NPE and partition map exchange hang.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-6979:
--
Description: 
Was reproduced on TC and locally using test
{{org.apache.ignite.internal.processors.cache.IgniteCachePartitionMapUpdateTest#testRandom}}

Reason: discoCache is not initalized before calling  
{{org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology#nodes(int,
 org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion, 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionState,
 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionState...)}}

Stacktrace on coordinator:

{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.nodes(GridClientPartitionTopology.java:538)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:577)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:582)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2117)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllRegisteredCacheGroups(CacheAffinitySharedManager.java:1059)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initAffinityOnNodeLeft0(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onServerLeftWithExchangeMergeProtocol(CacheAffinitySharedManager.java:1383)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2239)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2199)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1936)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1793)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1483)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:307)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2626)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2605)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 

[jira] [Created] (IGNITE-6979) Race in GridClientPartitionTopology may cause NPE and partition map exchange hang.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-6979:
-

 Summary: Race in GridClientPartitionTopology may cause NPE and 
partition map exchange hang.
 Key: IGNITE-6979
 URL: https://issues.apache.org/jira/browse/IGNITE-6979
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Alexei Scherbakov
 Fix For: 2.4


Was reproduced on TC and locally using test
{{org.apache.ignite.internal.processors.cache.IgniteCachePartitionMapUpdateTest#testRandom}}

Reason: discoCache is not initalized before calling  
{{org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology#nodes(int,
 org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion, 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionState,
 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionState...)}}

{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.nodes(GridClientPartitionTopology.java:538)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:577)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridClientPartitionTopology.owners(GridClientPartitionTopology.java:582)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2117)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$22.applyx(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllRegisteredCacheGroups(CacheAffinitySharedManager.java:1059)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initAffinityOnNodeLeft0(CacheAffinitySharedManager.java:2043)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onServerLeftWithExchangeMergeProtocol(CacheAffinitySharedManager.java:1383)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2239)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2199)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1936)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1793)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1781)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1483)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:307)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2626)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2605)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-5874 at 11/21/17 4:30 PM:
--

Test demonstrating issue with rebalancing for PDS and TTL attached
also test code can be found in 
https://github.com/apache/ignite/compare/master...gridgain:ignite-6964


was (Author: dpavlov):
Test demonstrating issue with rebalancing for PDS and TTL attached

> 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
> 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] [Commented] (IGNITE-6964) Ignite restart with PDS enabled may cause delays in TTL cleanup worker

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6964:


Test code can be found in 
https://github.com/apache/ignite/compare/master...gridgain:ignite-6964

> Ignite restart with PDS enabled may cause delays in TTL cleanup worker
> --
>
> Key: IGNITE-6964
> URL: https://issues.apache.org/jira/browse/IGNITE-6964
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
> Fix For: 2.4
>
>
> If ignite was restarted and not all TTL entries were evicted, simple restart 
> does not cause entries to be deleted, even if test waits for some time.
> In the same time if some entries were touched by get() TTL eviction starts to 
> work as it is expected.



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5874:


Without this fix following assertion is occurred:
{noformat}
Caused by: java.lang.AssertionError: FullPageId [pageId=00010005, 
effectivePageId=0005, grpId=-1237460590]
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:624)
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:521)
at 
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:140)
at 
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:102)
at 
org.apache.ignite.internal.processors.cache.tree.PendingRow.initKey(PendingRow.java:72)
at 
org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:116)
at 
org.apache.ignite.internal.processors.cache.tree.PendingEntriesTree.getRow(PendingEntriesTree.java:31)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer(BPlusTree.java:4539)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.init(BPlusTree.java:4441)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.access$5300(BPlusTree.java:4380)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetCursor.notFound(BPlusTree.java:2527)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:276)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4695)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4680)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:158)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.read(DataStructure.java:319)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown(BPlusTree.java:1121)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown(BPlusTree.java:1130)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind(BPlusTree.java:1090)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$15800(BPlusTree.java:81)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.find(BPlusTree.java:4595)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.access$5400(BPlusTree.java:4380)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:946)
{noformat}

> 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
> 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] [Updated] (IGNITE-5874) Store TTL expire times in B+ tree on per-partition basis

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-5874:
---
Component/s: persistence

> 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
>
> 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] [Assigned] (IGNITE-5641) Web Console: In addition to export also implement copy result set to clipboard.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-5641:


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

Looks good. Merged to master.

> Web Console: In addition to export also implement copy result set to 
> clipboard.
> ---
>
> Key: IGNITE-5641
> URL: https://issues.apache.org/jira/browse/IGNITE-5641
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>




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

[jira] [Commented] (IGNITE-6958) Reduce FilePageStore allocation on start

[Alexander Belyak (JIRA)]

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

Alexander Belyak commented on IGNITE-6958:
--

Minor memory consumption even in huge topologies/cacheGroup numbers.

> Reduce FilePageStore allocation on start
> 
>
> Key: IGNITE-6958
> URL: https://issues.apache.org/jira/browse/IGNITE-6958
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Minor
>
> On cache start ignite create FilePageStore for all partition in CacheGroup, 
> even if that partition never assigned to particular node. See 
> FilePageStoreManager.initForCache method.



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

[jira] [Updated] (IGNITE-6977) Wrong initial BitSet size in GridPartitionStateMap

[Alexander Belyak (JIRA)]

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

Alexander Belyak updated IGNITE-6977:
-
Priority: Minor  (was: Major)

> Wrong initial BitSet size in GridPartitionStateMap
> --
>
> Key: IGNITE-6977
> URL: https://issues.apache.org/jira/browse/IGNITE-6977
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Minor
>
> In constructor of org.apache.ignite.internal.utilGridPartitionStateMap(int 
> parts) {
> states = new BitSet(parts);
> }
> we initialize BitSet with part bit, but use private static final int BITS for 
> each partition state. As result long[] in BitSet get difficult predictable 
> size (depends of access order it can be exact as needed or almost twice 
> bigger with at least one additional array copying)



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

[jira] [Updated] (IGNITE-6958) Reduce FilePageStore allocation on start

[Alexander Belyak (JIRA)]

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

Alexander Belyak updated IGNITE-6958:
-
Priority: Minor  (was: Major)

> Reduce FilePageStore allocation on start
> 
>
> Key: IGNITE-6958
> URL: https://issues.apache.org/jira/browse/IGNITE-6958
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Minor
>
> On cache start ignite create FilePageStore for all partition in CacheGroup, 
> even if that partition never assigned to particular node. See 
> FilePageStoreManager.initForCache method.



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

[jira] [Updated] (IGNITE-6978) Failed to move temp file to a regular WAL segment file

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin updated IGNITE-6978:
-
Attachment: 172.25.1.62.zip

> Failed to move temp file to a regular WAL segment file
> --
>
> Key: IGNITE-6978
> URL: https://issues.apache.org/jira/browse/IGNITE-6978
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: CentOS
>Reporter: Oleg Ostanin
> Attachments: 172.25.1.62.zip
>
>
> 1. I've started 2 server nodes on 2 hosts.
> 2. Started 2 client nodes, one on each host
> 3. Started DataStreamer from the first client with a key range 0-100 and 
> from the second client with a key range 100-200
> Then got this exception: 
> Failed to set initial value for cache entry: DataStreamerEntry 
> [key=KeyCacheObjectImpl [part=157, val=190623, hasValBytes=true], 
> val=o.a.i.scenario.internal.model.SampleObject [idHash=2108267055, 
> hash=2007824273, salary=1000, fields=HashMap {field19=aupygsskxq, 
> field17=vghghwpdkk, field18=wapmsogviv, field22=yhsgrgxjvt, 
> field23=bkuzgwohlp, field20=mzcimhrkwl, field21=bkdlrjeosd, 
> field26=wvlypybaop, field27=wqmetfzsdm, field24=vpmmxinygq, 
> field25=idbcqlchvq, field11=zkuxmemury, field12=otkuigrzqj, 
> field10=uvghlcvwlx, field15=gaootfgcis, field16=abwxazoyoa, 
> field13=flgmuzijzh, field14=vzsmgclizh, field39=iqhielhnon, 
> field44=joadulhoxf, field45=bwqqkumjgf, field42=epwlotiwbv, 
> field43=cvlehgeyar, field48=gnjawjgbrp, field49=ptfzndiiqm, 
> field46=dkmbtdsrcr, field47=smugvczqkk, field40=kgozmlfenp, 
> field41=bxtvofscdp, field28=enfjjtysvt, field29=kbzlsguqcb, 
> field33=mbixfddhsq, field34=rygvisgdbi, field1=qriiuymvwe, 
> field31=hdqfmkyofe, field0=comhcshciq, field32=lwroifzwfa, 
> field37=gnooplphem, field38=zembqqqnzm, field35=pbpgfjvmhs, 
> field36=eqbvpwenrd, field7=ymzwgutylc, field6=slnusxjggw, field9=psfzikqbyg, 
> field8=exrrvedqvo, field3=dcilcjrprt, field2=yozawivutp, field30=ptreqavpui, 
> field5=kxacmhbusc, field4=yxymejnvos}]]
> org.apache.ignite.IgniteCheckedException: Failed to move temp file to a 
> regular WAL segment file: 
> /storage/ssd/oostanin/poc-tester/work/db/wal/poc_tester_server1/0005.wal
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:987)
>  ~[ignite-core-2.1.6.jar:2.1.6]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:1432)
>  ~[ignite-core-2.1.6.jar:2.1.6]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4900(FileWriteAheadLogManager.java:89)
>  ~[ignite-core-2.1.6.jar:2.1.6]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManager.java:1402)
>  ~[ignite-core-2.1.6.jar:2.1.6]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.run(FileWriteAheadLogManager.java:1187)
>  ~[ignite-core-2.1.6.jar:2.1.6]
> Caused by: java.nio.file.FileAlreadyExistsException: 
> /storage/ssd/oostanin/poc-tester/work/db/wal/poc_tester_server1/0005.wal
>   at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:429) ~[?:1.8.0_151]
>   at 
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262) 
> ~[?:1.8.0_151]
>   at java.nio.file.Files.move(Files.java:1395) ~[?:1.8.0_151]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:984)
>  ~[ignite-core-2.1.6.jar:2.1.6]
>   ... 4 more
>  



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

[jira] [Created] (IGNITE-6978) Failed to move temp file to a regular WAL segment file

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-6978:


 Summary: Failed to move temp file to a regular WAL segment file
 Key: IGNITE-6978
 URL: https://issues.apache.org/jira/browse/IGNITE-6978
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
 Environment: CentOS
Reporter: Oleg Ostanin


1. I've started 2 server nodes on 2 hosts.
2. Started 2 client nodes, one on each host
3. Started DataStreamer from the first client with a key range 0-100 and 
from the second client with a key range 100-200

Then got this exception: 
Failed to set initial value for cache entry: DataStreamerEntry 
[key=KeyCacheObjectImpl [part=157, val=190623, hasValBytes=true], 
val=o.a.i.scenario.internal.model.SampleObject [idHash=2108267055, 
hash=2007824273, salary=1000, fields=HashMap {field19=aupygsskxq, 
field17=vghghwpdkk, field18=wapmsogviv, field22=yhsgrgxjvt, field23=bkuzgwohlp, 
field20=mzcimhrkwl, field21=bkdlrjeosd, field26=wvlypybaop, field27=wqmetfzsdm, 
field24=vpmmxinygq, field25=idbcqlchvq, field11=zkuxmemury, field12=otkuigrzqj, 
field10=uvghlcvwlx, field15=gaootfgcis, field16=abwxazoyoa, field13=flgmuzijzh, 
field14=vzsmgclizh, field39=iqhielhnon, field44=joadulhoxf, field45=bwqqkumjgf, 
field42=epwlotiwbv, field43=cvlehgeyar, field48=gnjawjgbrp, field49=ptfzndiiqm, 
field46=dkmbtdsrcr, field47=smugvczqkk, field40=kgozmlfenp, field41=bxtvofscdp, 
field28=enfjjtysvt, field29=kbzlsguqcb, field33=mbixfddhsq, field34=rygvisgdbi, 
field1=qriiuymvwe, field31=hdqfmkyofe, field0=comhcshciq, field32=lwroifzwfa, 
field37=gnooplphem, field38=zembqqqnzm, field35=pbpgfjvmhs, field36=eqbvpwenrd, 
field7=ymzwgutylc, field6=slnusxjggw, field9=psfzikqbyg, field8=exrrvedqvo, 
field3=dcilcjrprt, field2=yozawivutp, field30=ptreqavpui, field5=kxacmhbusc, 
field4=yxymejnvos}]]
org.apache.ignite.IgniteCheckedException: Failed to move temp file to a regular 
WAL segment file: 
/storage/ssd/oostanin/poc-tester/work/db/wal/poc_tester_server1/0005.wal
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:987)
 ~[ignite-core-2.1.6.jar:2.1.6]
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:1432)
 ~[ignite-core-2.1.6.jar:2.1.6]
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4900(FileWriteAheadLogManager.java:89)
 ~[ignite-core-2.1.6.jar:2.1.6]
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManager.java:1402)
 ~[ignite-core-2.1.6.jar:2.1.6]
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.run(FileWriteAheadLogManager.java:1187)
 ~[ignite-core-2.1.6.jar:2.1.6]
Caused by: java.nio.file.FileAlreadyExistsException: 
/storage/ssd/oostanin/poc-tester/work/db/wal/poc_tester_server1/0005.wal
at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:429) ~[?:1.8.0_151]
at 
sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262) 
~[?:1.8.0_151]
at java.nio.file.Files.move(Files.java:1395) ~[?:1.8.0_151]
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:984)
 ~[ignite-core-2.1.6.jar:2.1.6]
... 4 more

 



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

[jira] [Commented] (IGNITE-2766) Cache instance is closed when client disconnects

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2766:


GitHub user alamar opened a pull request:

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

IGNITE-2766 Ensure that cache is available after client ID changes.



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

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

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

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






> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Commented] (IGNITE-6171) Native facility to control excessive GC pauses

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin commented on IGNITE-6171:
-

[~avinogradov], please review patch.

> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7, usability
> Fix For: 2.4
>
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Updated] (IGNITE-4394) Web console: memory leak when dialog "Connection to Ignite Node is not established" on the screen

[Alexey Kuznetsov (JIRA)]

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

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

> Web console: memory leak when dialog "Connection to Ignite Node is not 
> established" on the screen
> -
>
> Key: IGNITE-4394
> URL: https://issues.apache.org/jira/browse/IGNITE-4394
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>  Time Spent: 0.1m
>  Remaining Estimate: 0h
>
> I've noticed memory leak in case when dialog is opened during long period.



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

[jira] [Commented] (IGNITE-6949) Cleanup OLS code

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev commented on IGNITE-6949:
--

[~chief] please review, I formatted changed files with codestyle file from 
ignite/idea

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Updated] (IGNITE-6348) Web Console: Implement control for selecting and activating cluster

[Alexey Kuznetsov (JIRA)]

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

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

> Web Console: Implement control for selecting and activating cluster
> ---
>
> Key: IGNITE-6348
> URL: https://issues.apache.org/jira/browse/IGNITE-6348
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Dmitriy Shabalin
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> We need a control to select cluster and activate / deactivate it.



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6867:
--

[~alex_pl]
Could you please make prereview?

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



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

[jira] [Reopened] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii reopened IGNITE-6802:


Misclick - from In progress it should be moved to patch available.

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>  Labels: newbie, usability
> Fix For: 2.4
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



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

[jira] [Created] (IGNITE-6977) Wrong initial BitSet size in GridPartitionStateMap

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-6977:


 Summary: Wrong initial BitSet size in GridPartitionStateMap
 Key: IGNITE-6977
 URL: https://issues.apache.org/jira/browse/IGNITE-6977
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.1
Reporter: Alexander Belyak


In constructor of org.apache.ignite.internal.utilGridPartitionStateMap(int 
parts) {
states = new BitSet(parts);
}
we initialize BitSet with part bit, but use private static final int BITS for 
each partition state. As result long[] in BitSet get difficult predictable size 
(depends of access order it can be exact as needed or almost twice bigger with 
at least one additional array copying)



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

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

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-6976:


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






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

[jira] [Assigned] (IGNITE-6890) Proper behavior on ExchangeWorker exits with error

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin reassigned IGNITE-6890:
---

Assignee: Dmitriy Sorokin

> Proper behavior on ExchangeWorker exits with error 
> ---
>
> Key: IGNITE-6890
> URL: https://issues.apache.org/jira/browse/IGNITE-6890
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7
> Fix For: 2.4
>
>
> Node should be stopped anyway, what we can provide is user callback, 
> something like beforeNodeStop'.



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

[jira] [Created] (IGNITE-6975) .NET: Create cross-platform examples on .NET Core

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6975:
--

 Summary: .NET: Create cross-platform examples on .NET Core
 Key: IGNITE-6975
 URL: https://issues.apache.org/jira/browse/IGNITE-6975
 Project: Ignite
  Issue Type: Improvement
  Components: examples, platforms
Affects Versions: 2.4
Reporter: Pavel Tupitsyn


IGNITE-2662 brings .NET Core based cross-platform support. We should provide 
examples that can be run on any platform (Windows / Linux / Mac).

Existing examples should be kept for .NET 4.0 / VS 2010 support.



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

[jira] [Updated] (IGNITE-6963) TotalAllocatedPages metric does not match PhysicalMemoryPages when persistence is disabled

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6963:
-
Fix Version/s: 2.4

> TotalAllocatedPages metric does not match PhysicalMemoryPages when 
> persistence is disabled
> --
>
> Key: IGNITE-6963
> URL: https://issues.apache.org/jira/browse/IGNITE-6963
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> As javadoc states for DataRegionMetrics#getPhysicalMemoryPages()
> {noformat}
> When persistence is disabled, this metric is equal to getTotalAllocatedPages()
> {noformat}
> and this seems to be sane requirement.



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

[jira] [Commented] (IGNITE-6171) Native facility to control excessive GC pauses

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6171:


GitHub user x-kreator opened a pull request:

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

IGNITE-6171: + LongJVMPauseDetector, + longJVMPausesCount and longJVM…

…PausesTotalDuration properties of IgniteMXBean.

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

$ git pull https://github.com/x-kreator/ignite ignite-6171

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

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


commit 37283985ff4a52d28691762fec1e99cc828ec762
Author: Unknown 
Date:   2017-11-21T13:38:29Z

IGNITE-6171: + LongJVMPauseDetector, + longJVMPausesCount and 
longJVMPausesTotalDuration properties of IgniteMXBean.




> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7, usability
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Updated] (IGNITE-6623) Web console: export query result set doesn't work on Edge

[Alexey Kuznetsov (JIRA)]

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

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

> Web console: export query result set doesn't work on Edge
> -
>
> Key: IGNITE-6623
> URL: https://issues.apache.org/jira/browse/IGNITE-6623
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> Execute any query and try to Export\ExportAll in result table



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

[jira] [Assigned] (IGNITE-6914) Web console: 'Export All' for scan stucks in Chrome but successfully finish in FireFox

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6914:


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

Looks good. Merged to master.

> Web console: 'Export All' for scan stucks in Chrome but successfully finish 
> in FireFox
> --
>
> Key: IGNITE-6914
> URL: https://issues.apache.org/jira/browse/IGNITE-6914
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> I populated a cache with 100K of data.
> Then I opened Query screen and execute Scan for that cache.
> Then I executed Export All - under Chrome it stuck



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

[jira] [Resolved] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii resolved IGNITE-6802.

Resolution: Fixed

> NullPointerException when WAL store and WAL archive paths are same 
> ---
>
> Key: IGNITE-6802
> URL: https://issues.apache.org/jira/browse/IGNITE-6802
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Alexey Kukushkin
>Assignee: Ryabov Dmitrii
>  Labels: newbie, usability
> Fix For: 2.4
>
>
> Configuring WAL store and WAL archive paths to be the same results in 
> NullPointerException. We should display a meaningful error about the 
> misconfiguration instead.
> See 
> http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
> The thread includes the reproducer code and stack trace. I was able to 
> reproduce the issue with today's (31-Oct-2017) Apache master.



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

[jira] [Updated] (IGNITE-6914) Web console: 'Export All' for scan stucks in Chrome but successfully finish in FireFox

[Alexey Kuznetsov (JIRA)]

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

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

> Web console: 'Export All' for scan stucks in Chrome but successfully finish 
> in FireFox
> --
>
> Key: IGNITE-6914
> URL: https://issues.apache.org/jira/browse/IGNITE-6914
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> I populated a cache with 100K of data.
> Then I opened Query screen and execute Scan for that cache.
> Then I executed Export All - under Chrome it stuck



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

[jira] [Commented] (IGNITE-6171) Native facility to control excessive GC pauses

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6171:
--

[~vozerov]

We're only interested in monitoring pauses exceeding some duration, which shows 
GC health situation.
Also, we're interested to monitor only STW or similar cases, when all Ignite 
threads paused.

As far as I see, we can't reach this information from {{GarbageCollectorMXBean}}
So, we're working on new incremental metrics
1) total amount of pauses longer than XXX
2) total duration of pauses longer than XXX


> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7, usability
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Assigned] (IGNITE-4454) Web console: add information on query panel UI about node query was executed on

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4454:


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

Looks good. Merged to master.

> Web console: add information on query panel  UI about node query was executed 
> on
> 
>
> Key: IGNITE-4454
> URL: https://issues.apache.org/jira/browse/IGNITE-4454
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.4
>
>
> Currently we show only query text  and do not show node in case of 'Execute 
> on selected node'



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

[jira] [Commented] (IGNITE-6171) Native facility to control excessive GC pauses

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin commented on IGNITE-6171:
-

[~vozerov], [~avinogradov]
Implementations and, moreover, existence of that bean may be different in 
different jvm implementations. Also, pauses theoretically may has cause other 
than GC STWs.

> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7, usability
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Comment Edited] (IGNITE-425) Introduce transformers for continuous queries

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-425 at 11/21/17 12:31 PM:
---

[~avinogradov] Hello, did you have a chance to review the ticket?

Maybe you can propose any other commiter to review and merge this ticket?

Hello, [~yzhdanov]. This ticket waits for final review and merge almost 2 
months.
Can you, please, as the author of the ticket review and merge PR?


was (Author: nizhikov):
[~avinogradov] Hello, did you have a chance to review the ticket?

May be you can propose any other commiter to review and merge this ticket?

Hello, [~yzhdanov]. This ticket waits for final review and merge almost 2 month.
Can you, please, as the author of the ticket review PR?

> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 2.2
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
> Fix For: 2.4
>
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



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

[jira] [Commented] (IGNITE-425) Introduce transformers for continuous queries

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-425:


[~avinogradov] Hello, did you have a chance to review the ticket?

May be you can propose any other commiter to review and merge this ticket?

Hello, [~yzhdanov]. This ticket waits for final review and merge almost 2 month.
Can you, please, as the author of the ticket review PR?

> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 2.2
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
> Fix For: 2.4
>
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



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

[jira] [Updated] (IGNITE-6974) .NET: consoleWrite error during application shutdown

[Pavel Tupitsyn (JIRA)]

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

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

> .NET: consoleWrite error during application shutdown
> 
>
> Key: IGNITE-6974
> URL: https://issues.apache.org/jira/browse/IGNITE-6974
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Priority: Minor
>  Labels: .NET
>
> from Gitter:
> Hey all (again xD)! Using Apache Ignite .NET 2.3 I (sometimes) get an error 
> when shutting down my application. The error is only observable on server 
> nodes and not on every shutdown. Seems like a kind of race condition.
> The application runs as windows service. The windows application event log 
> shows the following error (see above) and a I get a hs_err_pid[PID].log like 
> that (snip):
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.consoleWrite(Ljava/lang/String;Z)V+0
> j  
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.consoleWrite(Ljava/lang/String;Z)V+2
> j  
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetConsoleStream.write([BII)V+18
> j  java.io.PrintStream.write([BII)V+16
> j  sun.nio.cs.StreamEncoder.writeBytes()V+120
> j  sun.nio.cs.StreamEncoder.implFlushBuffer()V+11
> j  sun.nio.cs.StreamEncoder.flushBuffer()V+15
> j  java.io.OutputStreamWriter.flushBuffer()V+4
> j  java.io.PrintStream.write(Ljava/lang/String;)V+27
> j  java.io.PrintStream.print(Ljava/lang/String;)V+9
> j  
> org.apache.ignite.internal.util.IgniteUtils.quiet(Z[Ljava/lang/Object;)V+126
> j  org.apache.ignite.internal.IgniteKernal.stop0(Z)V+943
> j  org.apache.ignite.internal.IgniteKernal.stop(Z)V+6
> j  org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(Z)V+162
> j  org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(Z)V+26
> j  org.apache.ignite.internal.IgnitionEx.stop(Ljava/lang/String;ZZ)Z+72
> j  org.apache.ignite.Ignition.stop(Ljava/lang/String;Z)Z+3
> j  
> org.apache.ignite.internal.processors.platform.PlatformIgnition.stop(Ljava/lang/String;Z)Z+2
> v  ~StubRoutines::call_stub
> For me it seems that the Java side wants to write something to the (.NET) 
> console using a callback and the underlying memory is already freed - 
> therefore we get a AccessViolation



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

[jira] [Updated] (IGNITE-6974) .NET: consoleWrite error during application shutdown

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-6974:
---
Affects Version/s: 2.3

> .NET: consoleWrite error during application shutdown
> 
>
> Key: IGNITE-6974
> URL: https://issues.apache.org/jira/browse/IGNITE-6974
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Priority: Minor
>  Labels: .NET
>
> from Gitter:
> Hey all (again xD)! Using Apache Ignite .NET 2.3 I (sometimes) get an error 
> when shutting down my application. The error is only observable on server 
> nodes and not on every shutdown. Seems like a kind of race condition.
> The application runs as windows service. The windows application event log 
> shows the following error (see above) and a I get a hs_err_pid[PID].log like 
> that (snip):
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.consoleWrite(Ljava/lang/String;Z)V+0
> j  
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.consoleWrite(Ljava/lang/String;Z)V+2
> j  
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetConsoleStream.write([BII)V+18
> j  java.io.PrintStream.write([BII)V+16
> j  sun.nio.cs.StreamEncoder.writeBytes()V+120
> j  sun.nio.cs.StreamEncoder.implFlushBuffer()V+11
> j  sun.nio.cs.StreamEncoder.flushBuffer()V+15
> j  java.io.OutputStreamWriter.flushBuffer()V+4
> j  java.io.PrintStream.write(Ljava/lang/String;)V+27
> j  java.io.PrintStream.print(Ljava/lang/String;)V+9
> j  
> org.apache.ignite.internal.util.IgniteUtils.quiet(Z[Ljava/lang/Object;)V+126
> j  org.apache.ignite.internal.IgniteKernal.stop0(Z)V+943
> j  org.apache.ignite.internal.IgniteKernal.stop(Z)V+6
> j  org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(Z)V+162
> j  org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(Z)V+26
> j  org.apache.ignite.internal.IgnitionEx.stop(Ljava/lang/String;ZZ)Z+72
> j  org.apache.ignite.Ignition.stop(Ljava/lang/String;Z)Z+3
> j  
> org.apache.ignite.internal.processors.platform.PlatformIgnition.stop(Ljava/lang/String;Z)Z+2
> v  ~StubRoutines::call_stub
> For me it seems that the Java side wants to write something to the (.NET) 
> console using a callback and the underlying memory is already freed - 
> therefore we get a AccessViolation



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

[jira] [Created] (IGNITE-6974) .NET: consoleWrite error during application shutdown

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-6974:


 Summary: .NET: consoleWrite error during application shutdown
 Key: IGNITE-6974
 URL: https://issues.apache.org/jira/browse/IGNITE-6974
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Alexey Popov
Priority: Minor


from Gitter:

Hey all (again xD)! Using Apache Ignite .NET 2.3 I (sometimes) get an error 
when shutting down my application. The error is only observable on server nodes 
and not on every shutdown. Seems like a kind of race condition.
The application runs as windows service. The windows application event log 
shows the following error (see above) and a I get a hs_err_pid[PID].log like 
that (snip):
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.consoleWrite(Ljava/lang/String;Z)V+0
j  
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.consoleWrite(Ljava/lang/String;Z)V+2
j  
org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetConsoleStream.write([BII)V+18
j  java.io.PrintStream.write([BII)V+16
j  sun.nio.cs.StreamEncoder.writeBytes()V+120
j  sun.nio.cs.StreamEncoder.implFlushBuffer()V+11
j  sun.nio.cs.StreamEncoder.flushBuffer()V+15
j  java.io.OutputStreamWriter.flushBuffer()V+4
j  java.io.PrintStream.write(Ljava/lang/String;)V+27
j  java.io.PrintStream.print(Ljava/lang/String;)V+9
j  org.apache.ignite.internal.util.IgniteUtils.quiet(Z[Ljava/lang/Object;)V+126
j  org.apache.ignite.internal.IgniteKernal.stop0(Z)V+943
j  org.apache.ignite.internal.IgniteKernal.stop(Z)V+6
j  org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(Z)V+162
j  org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(Z)V+26
j  org.apache.ignite.internal.IgnitionEx.stop(Ljava/lang/String;ZZ)Z+72
j  org.apache.ignite.Ignition.stop(Ljava/lang/String;Z)Z+3
j  
org.apache.ignite.internal.processors.platform.PlatformIgnition.stop(Ljava/lang/String;Z)Z+2
v  ~StubRoutines::call_stub
For me it seems that the Java side wants to write something to the (.NET) 
console using a callback and the underlying memory is already freed - therefore 
we get a AccessViolation



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

[jira] [Assigned] (IGNITE-6973) Node restarts with enabled persistence lead to affinity assignment mismatch on different nodes.

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-6973:


Assignee: Semen Boikov

> Node restarts with enabled persistence lead to affinity assignment mismatch 
> on different nodes.
> ---
>
> Key: IGNITE-6973
> URL: https://issues.apache.org/jira/browse/IGNITE-6973
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Semen Boikov
> Fix For: 2.4
>
>
> Most probably this is caused by deploymentId reassign after grid restart.
> All nodes must have same deploymentId in such case.
> Reproducer:
> {noformat}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.internal.processors.cache.persistence;
> import java.util.Arrays;
> import java.util.Collection;
> import java.util.HashMap;
> import java.util.List;
> import java.util.Map;
> import java.util.concurrent.Callable;
> import java.util.concurrent.atomic.AtomicInteger;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.configuration.MemoryPolicyConfiguration;
> import org.apache.ignite.configuration.PersistentStoreConfiguration;
> import org.apache.ignite.configuration.WALMode;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.internal.IgniteInternalFuture;
> import org.apache.ignite.internal.IgniteKernal;
> import org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion;
> import org.apache.ignite.internal.processors.cache.CacheGroupDescriptor;
> import org.apache.ignite.internal.processors.cache.IgniteInternalCache;
> import org.apache.ignite.internal.util.typedef.G;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.lang.IgniteUuid;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
> import static 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.IGNITE_PDS_CHECKPOINT_TEST_SKIP_SYNC;
> /**
>  * The test validates assignment after nodes restart with enabled persistence.
>  */
> public class IgnitePdsCacheAssignmentNodeRestartsTest extends 
> GridCommonAbstractTest {
> /** */
> private static TcpDiscoveryIpFinder ipFinder = new 
> TcpDiscoveryVmIpFinder(true);
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setMemoryConfiguration(new 
> MemoryConfiguration().setDefaultMemoryPolicyName("d").
> setPageSize(1024).setMemoryPolicies(new 
> MemoryPolicyConfiguration().setName("d").
> setInitialSize(50 * 1024 * 1024L).setMaxSize(50 * 1024 * 
> 1024)));
> cfg.setPersistentStoreConfiguration(new 
> PersistentStoreConfiguration().setWalMode(WALMode.LOG_ONLY));
> ((TcpDiscoverySpi)cfg.getDiscoverySpi()).setIpFinder(ipFinder);
> return cfg;
> }
> /** {@inheritDoc} 

[jira] [Commented] (IGNITE-6171) Native facility to control excessive GC pauses

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6171:
-

[~avinogradov], [~cyberdemon], 
In this case 3-rd party users may simply use {{GarbageCollectorMXBean}} [1], 
Would it be enough?

[1] 
https://docs.oracle.com/javase/8/docs/jre/api/management/extension/com/sun/management/GarbageCollectorMXBean.html

> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7, usability
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Commented] (IGNITE-6171) Native facility to control excessive GC pauses

[Dmitriy Sorokin (JIRA)]

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

Dmitriy Sorokin commented on IGNITE-6171:
-

We discussed with [~avinogradov] the set of required metrics, and worked out 
the decision that the metrics will be values of total count and duration of 
pauses exceeding the threshold.

> Native facility to control excessive GC pauses
> --
>
> Key: IGNITE-6171
> URL: https://issues.apache.org/jira/browse/IGNITE-6171
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
>  Labels: iep-7, usability
>
> Ignite is Java-based application. If node experiences long GC pauses it may 
> negatively affect other nodes. We need to find a way to detect long GC pauses 
> within the process and trigger some actions in response, e.g. node stop. 
> This is a kind of Inception \[1\], when you need to understand that you sleep 
> while sleeping. As all Java threads are blocked on safepoint, we cannot use 
> Java's thread to detect Java's GC. Native threads should be used instead.
> Proposed solution:
> 1) Thread 1 should periodically call dummy JNI method returning current time, 
> and set this time to shared variable;
> 2) Thread 2 should periodically check that variable. If it has not been 
> changed for some time - most likely we are in GC pause. Once certain 
> threashold is reached - trigger compensating action, whether this is a 
> warning, process kill, or what so ever.
> Justification: crossing native -> Java boundaries involves safepoints. This 
> way Thread 1 will be trapped if STW pause is in progress. Java method cannot 
> be empty, as JVM is smart enough and can deduce it to no-op. 
> \[1\] http://www.imdb.com/title/tt1375666/



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

[jira] [Created] (IGNITE-6973) Node restarts with enabled persistence lead to affinity assignment mismatch on different nodes.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-6973:
-

 Summary: Node restarts with enabled persistence lead to affinity 
assignment mismatch on different nodes.
 Key: IGNITE-6973
 URL: https://issues.apache.org/jira/browse/IGNITE-6973
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Alexei Scherbakov
 Fix For: 2.4


Most probably this is caused by deploymentId reassign after grid restart.

All nodes must have same deploymentId in such case.

Reproducer:

{noformat}
/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.ignite.internal.processors.cache.persistence;

import java.util.Arrays;
import java.util.Collection;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.concurrent.Callable;
import java.util.concurrent.atomic.AtomicInteger;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.cache.CacheAtomicityMode;
import org.apache.ignite.cache.CacheMode;
import org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction;
import org.apache.ignite.cluster.ClusterNode;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.configuration.MemoryConfiguration;
import org.apache.ignite.configuration.MemoryPolicyConfiguration;
import org.apache.ignite.configuration.PersistentStoreConfiguration;
import org.apache.ignite.configuration.WALMode;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.internal.IgniteInternalFuture;
import org.apache.ignite.internal.IgniteKernal;
import org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion;
import org.apache.ignite.internal.processors.cache.CacheGroupDescriptor;
import org.apache.ignite.internal.processors.cache.IgniteInternalCache;
import org.apache.ignite.internal.util.typedef.G;
import org.apache.ignite.internal.util.typedef.internal.U;
import org.apache.ignite.lang.IgniteUuid;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.apache.ignite.testframework.GridTestUtils;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;

import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
import static org.apache.ignite.cache.CacheMode.PARTITIONED;
import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
import static 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.IGNITE_PDS_CHECKPOINT_TEST_SKIP_SYNC;

/**
 * The test validates assignment after nodes restart with enabled persistence.
 */
public class IgnitePdsCacheAssignmentNodeRestartsTest extends 
GridCommonAbstractTest {
/** */
private static TcpDiscoveryIpFinder ipFinder = new 
TcpDiscoveryVmIpFinder(true);

/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String 
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);

cfg.setMemoryConfiguration(new 
MemoryConfiguration().setDefaultMemoryPolicyName("d").
setPageSize(1024).setMemoryPolicies(new 
MemoryPolicyConfiguration().setName("d").
setInitialSize(50 * 1024 * 1024L).setMaxSize(50 * 1024 * 
1024)));

cfg.setPersistentStoreConfiguration(new 
PersistentStoreConfiguration().setWalMode(WALMode.LOG_ONLY));

((TcpDiscoverySpi)cfg.getDiscoverySpi()).setIpFinder(ipFinder);

return cfg;
}

/** {@inheritDoc} */
@Override protected void beforeTest() throws Exception {
super.beforeTest();

deleteRecursively(U.resolveWorkDirectory(U.defaultWorkDirectory(), 
"db", false));
}

/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
stopAllGrids();

deleteRecursively(U.resolveWorkDirectory(U.defaultWorkDirectory(), 
"db", false));

super.afterTest();
}

[jira] [Comment Edited] (IGNITE-6949) Cleanup OLS code

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-6949 at 11/21/17 10:29 AM:
-

[~zaleslaw],
Thank you for your contribution! I've looked at the changes and still see some 
code style issues. For example 
* extra space in imports (SparseBlockDistributedMatrix file);
* CacheUtils#reduce has incorrect alignments;

[~chief],
Please, double check this changes again and help [~zaleslaw] with it. 


was (Author: ntikhonov):
[~zaleslaw],
Thank you for your contribution! I've looked at the changes and still see some 
code style issues. For example 
* extra space in imports (SparseBlockDistributedMatrix file);
* CacheUtils#reduce has incorrect alignments;
[~chief],
Please, double check this changes again and help [~zaleslaw] with it. 

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Commented] (IGNITE-6949) Cleanup OLS code

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-6949:
--

[~zaleslaw],
Thank you for your contribution! I've looked at the changes and still see some 
code style issues. For example 
* extra space in imports (SparseBlockDistributedMatrix file);
* CacheUtils#reduce has incorrect alignments;
[~chief],
Please, double check this changes again and help [~zaleslaw] with it. 

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Updated] (IGNITE-6972) BinaryObjectBuilderImpl.build is stuck when server cluster is restarted

[Jason Man (JIRA)]

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

Jason Man updated IGNITE-6972:
--
Description: 
When a client node is using a BinaryObjectBuilder to build a BinaryObject, the 
build() method could get stuck if the cluster is being restarted.

Thread dump of the stack is
{code}
"main" #1 prio=5 os_prio=0 tid=0x004d9000 nid=0x62ac waiting on condition 
[0x023bf000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:441)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:182)
at 
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:793)
at 
org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:752)
at 
org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:623)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:207)
at 
org.apache.ignite.internal.binary.builder.BinaryValueWithType.writeTo(BinaryValueWithType.java:48)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:313)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
...
{code}

Possible solution
Should we use the get(long timeout) instead of get() which never times out?

  was:
When a client node is using a BinaryObjectBuilder to build a BinaryObject, the 
build() method could get stuck if the cluster is being restarted.

Thread dump of the stack is
{code}
"main" #1 prio=5 os_prio=0 tid=0x004d9000 nid=0x62ac waiting on condition 
[0x023bf000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:441)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:182)
at 
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:793)
at 
org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:752)
at 
org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:623)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:207)
at 
org.apache.ignite.internal.binary.builder.BinaryValueWithType.writeTo(BinaryValueWithType.java:48)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:313)
at 

[jira] [Created] (IGNITE-6972) BinaryObjectBuilderImpl.build is stuck when server cluster is restarted

[Jason Man (JIRA)]

Jason Man created IGNITE-6972:
-

 Summary: BinaryObjectBuilderImpl.build is stuck when server 
cluster is restarted
 Key: IGNITE-6972
 URL: https://issues.apache.org/jira/browse/IGNITE-6972
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 2.3
Reporter: Jason Man


When a client node is using a BinaryObjectBuilder to build a BinaryObject, the 
build() method could get stuck if the cluster is being restarted.

Thread dump of the stack is
{code}
"main" #1 prio=5 os_prio=0 tid=0x004d9000 nid=0x62ac waiting on condition 
[0x023bf000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:441)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:182)
at 
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:793)
at 
org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:752)
at 
org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:623)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:207)
at 
org.apache.ignite.internal.binary.builder.BinaryValueWithType.writeTo(BinaryValueWithType.java:48)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
at 
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:313)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
...
{code}



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

[jira] [Commented] (IGNITE-6904) SQL: partition reservations are released too early in lazy mode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6904:


GitHub user dolphin1414 opened a pull request:

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

IGNITE-6904 SQL: partition reservations are released too early in lazy mode

In lazy mode partitions reservations are released only after last page has 
been sent.

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

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

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

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


commit c28dda18e185692c93f722996a03c70daab19bcd
Author: rkondakov 
Date:   2017-11-21T10:09:12Z

IGNITE-6904: in lazy mode partitions reservations are released only after 
last page has been sent.

commit 7dda28980eb792392454583f26970e31eb1727eb
Author: rkondakov 
Date:   2017-11-21T10:11:29Z

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

commit 153de4033fe53407ac7db9615891798e47b1dc19
Author: rkondakov 
Date:   2017-11-21T10:12:13Z

Merge remote-tracking branch 'origin/master' into ignite-6904




> SQL: partition reservations are released too early in lazy mode
> ---
>
> Key: IGNITE-6904
> URL: https://issues.apache.org/jira/browse/IGNITE-6904
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> In lazy mode we advance query execution as new page requests arrive. However, 
> method {{GridMapQueryExecutor#onQueryRequest0}} releases partition 
> reservations when only the very first page is processed:
> {code}
> finally {
> GridH2QueryContext.clearThreadLocal();
> if (distributedJoinMode == OFF)
> qctx.clearContext(false);
> }
> {code}
> It means that incorrect results may be returned on unstable topology. We need 
> to release partitions only after the whole query is executed.



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

[jira] [Resolved] (IGNITE-6437) DataStructure can not be obtained on client if it is created on server node.

[Semen Boikov (JIRA)]

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

Semen Boikov resolved IGNITE-6437.
--
Resolution: Fixed
  Assignee: (was: Semen Boikov)

[~zstan],

Thank you, merged into master.

> DataStructure can not be obtained on client if it is created on server node.
> 
>
> Key: IGNITE-6437
> URL: https://issues.apache.org/jira/browse/IGNITE-6437
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 2.1, 2.3
>Reporter: Mikhail Cherkasov
>Priority: Critical
> Fix For: 2.4
>
> Attachments: NoQueueOnClientNodeTest.java, tc_111.png
>
>
> DataStructure can not be obtained on client if it is created on server node.



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

[jira] [Updated] (IGNITE-4454) Web console: add information on query panel UI about node query was executed on

[Alexey Kuznetsov (JIRA)]

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

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

> Web console: add information on query panel  UI about node query was executed 
> on
> 
>
> Key: IGNITE-4454
> URL: https://issues.apache.org/jira/browse/IGNITE-4454
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.4
>
>
> Currently we show only query text  and do not show node in case of 'Execute 
> on selected node'



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

[jira] [Commented] (IGNITE-6949) Cleanup OLS code

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-6949:


I reviewed this PR, looks good for me.

> Cleanup OLS code
> 
>
> Key: IGNITE-6949
> URL: https://issues.apache.org/jira/browse/IGNITE-6949
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
> Fix For: 2.4
>
>
> We want fix wrong styles like wildcards in imports, unnecessary empty lines, 
> missed empty lines and if-else blocks format in OLS related files.



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

[jira] [Commented] (IGNITE-6966) Average time metrics are not calculated for client driven operations

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6966:
-

It's known issue and duplicates IGNITE-3495.

> Average time metrics are not calculated for client driven operations
> 
>
> Key: IGNITE-6966
> URL: https://issues.apache.org/jira/browse/IGNITE-6966
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> Cache operations executed from a client-side are not accounted in average 
> time metrics. Use this reproducer [1] performing the following:
> * Start a server node [2] that will report 
> {{getAveragePutTime}}/{{getAverageGetTime}} metrics in a loop.
> * Start a client node [3] that will report the same metrics and do cache 
> updates/reads.
> Both nodes show {{0}} for those metrics.
> [1] https://github.com/dmagda/IgniteMetricsExampe/
> [2] 
> https://github.com/dmagda/IgniteMetricsExampe/blob/master/src/main/java/IgniteMetricsExample.java
> [3] 
> https://github.com/dmagda/IgniteMetricsExampe/blob/master/src/main/java/IgniteClientMetricsExample.java



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

[jira] [Resolved] (IGNITE-6966) Average time metrics are not calculated for client driven operations

[Andrey Gura (JIRA)]

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

Andrey Gura resolved IGNITE-6966.
-
Resolution: Duplicate

> Average time metrics are not calculated for client driven operations
> 
>
> Key: IGNITE-6966
> URL: https://issues.apache.org/jira/browse/IGNITE-6966
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> Cache operations executed from a client-side are not accounted in average 
> time metrics. Use this reproducer [1] performing the following:
> * Start a server node [2] that will report 
> {{getAveragePutTime}}/{{getAverageGetTime}} metrics in a loop.
> * Start a client node [3] that will report the same metrics and do cache 
> updates/reads.
> Both nodes show {{0}} for those metrics.
> [1] https://github.com/dmagda/IgniteMetricsExampe/
> [2] 
> https://github.com/dmagda/IgniteMetricsExampe/blob/master/src/main/java/IgniteMetricsExample.java
> [3] 
> https://github.com/dmagda/IgniteMetricsExampe/blob/master/src/main/java/IgniteClientMetricsExample.java



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

[jira] [Commented] (IGNITE-6922) Class can not undeploy from grid in some specific cases

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov commented on IGNITE-6922:
---

[~agoncharuk]
Thanks for comment.
I have applied your proposals.
Could you please, review it again?

> Class can not undeploy from grid in some specific cases
> ---
>
> Key: IGNITE-6922
> URL: https://issues.apache.org/jira/browse/IGNITE-6922
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>
> Peer class loading enable on cluster and deployment mode set as SHARED.
> In several cases after master (so that who deploy a class) node leave cluster 
> and reconnect with other implementation, old implementation of the class 
> continue execute in grid.



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

[jira] [Commented] (IGNITE-6931) Simplify index rebuild

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6931:


Github user asfgit closed the pull request at:

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


> Simplify index rebuild
> --
>
> Key: IGNITE-6931
> URL: https://issues.apache.org/jira/browse/IGNITE-6931
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
> Fix For: 2.4
>
>
> There are two quite similar operations: CREATE INDEX rebuildIndexFromHach but 
> used approaches are absolutely different. We need to generalize an used 
> approach.



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

[jira] [Assigned] (IGNITE-6954) Baseline should throw appropriate exception in case of --baseline version OLD_VERSION

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6954:


Assignee: Pavel Konstantinov  (was: Sergey Chugunov)

[~pkonstantinov] Please test in branch.

> Baseline should throw appropriate exception in case of --baseline version 
> OLD_VERSION
> -
>
> Key: IGNITE-6954
> URL: https://issues.apache.org/jira/browse/IGNITE-6954
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Steps to reproduce:
> # Start node.
> # Activate it (it will create baseline).
> # Start one more node and add it to baseline.
> # Execute: control.sh --baseline version 1
> This should throw appropriate exception. 



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

[jira] [Comment Edited] (IGNITE-6390) [IGNITE-6390] Web console: Implement component for cluster selection on pages where it make sense

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6390 at 11/21/17 9:16 AM:


Please test cluster selection in branch ignite-6390-2.
How to test:
# Start Web console without clusters - check that all work as expected.
# Start first cluster - check that all work as expected.
# Start second cluster - check that all work as expected.
# Stop one of agent - check that all work as expected.
# Start agent again- check that all work as expected.
# Stop one cluster - check that all work as expected.
# Check Demo mode.


was (Author: kuaw26):
Please test cluster selection in branch ignite-6390-2.

> [IGNITE-6390] Web console: Implement component for cluster selection on pages 
> where it make sense
> -
>
> Key: IGNITE-6390
> URL: https://issues.apache.org/jira/browse/IGNITE-6390
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> 1. add cluster-selector to pages.
> 2. add update information of cluster data in page after change cluster.



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

[jira] [Assigned] (IGNITE-6390) [IGNITE-6390] Web console: Implement component for cluster selection on pages where it make sense

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6390:


Assignee: Pavel Konstantinov  (was: Dmitriy Shabalin)

Please test cluster selection in branch ignite-6390-2.

> [IGNITE-6390] Web console: Implement component for cluster selection on pages 
> where it make sense
> -
>
> Key: IGNITE-6390
> URL: https://issues.apache.org/jira/browse/IGNITE-6390
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> 1. add cluster-selector to pages.
> 2. add update information of cluster data in page after change cluster.



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

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

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-6971:


 Summary: Ignite Logger type & logging file config indication
 Key: IGNITE-6971
 URL: https://issues.apache.org/jira/browse/IGNITE-6971
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.1
Reporter: Alexey Popov
Priority: Minor


Please see 
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Logger-amp-logging-file-config-output-td24435.html



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

[jira] [Assigned] (IGNITE-4454) Web console: add information on query panel UI about node query was executed on

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-4454:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: add information on query panel  UI about node query was executed 
> on
> 
>
> Key: IGNITE-4454
> URL: https://issues.apache.org/jira/browse/IGNITE-4454
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> Currently we show only query text  and do not show node in case of 'Execute 
> on selected node'



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

[jira] [Commented] (IGNITE-4454) Web console: add information on query panel UI about node query was executed on

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4454:


Tested. Can be merged into the target branch.

> Web console: add information on query panel  UI about node query was executed 
> on
> 
>
> Key: IGNITE-4454
> URL: https://issues.apache.org/jira/browse/IGNITE-4454
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
>
> Currently we show only query text  and do not show node in case of 'Execute 
> on selected node'



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

[jira] [Commented] (IGNITE-6922) Class can not undeploy from grid in some specific cases

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-6922:
--

[~v.pyatkov],

Please remove System.err.println("") calls from the code, use 
`@IgniteInstanceResource` with Ignite injection to obtain an instance of log 
instead.

> Class can not undeploy from grid in some specific cases
> ---
>
> Key: IGNITE-6922
> URL: https://issues.apache.org/jira/browse/IGNITE-6922
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>
> Peer class loading enable on cluster and deployment mode set as SHARED.
> In several cases after master (so that who deploy a class) node leave cluster 
> and reconnect with other implementation, old implementation of the class 
> continue execute in grid.



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

[jira] [Created] (IGNITE-6970) Error thrown from CacheStore cause cache operation hanging.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-6970:


 Summary: Error thrown from CacheStore cause cache operation 
hanging.
 Key: IGNITE-6970
 URL: https://issues.apache.org/jira/browse/IGNITE-6970
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Andrew Mashenkov


If some error (e.g. NoSuchMethodError) was thrown from CacheStore 
implementation during simple cache.get(),
then operation hangs as server fails and never sends NearAtomicGetResponse to 
client
and never complete async future.

GridCacheAdapter.getAllAsync0 method failed on GridEmbeddedFuture creation.



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