[jira] [Assigned] (IGNITE-6968) Move similar Cache configurations in matrices and models to one Java or XML config

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev reassigned IGNITE-6968:


Assignee: Aleksey Zinoviev

> Move similar Cache configurations in matrices and models to one Java or XML 
> config
> --
>
> Key: IGNITE-6968
> URL: https://issues.apache.org/jira/browse/IGNITE-6968
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>
> There are a lot of copy-paste cache configs in matrices and vectors in method 
> newCache() which returns configured cache for different data structures
> For example
> * SparseDistributedMatrixStorage
> * BlockVectorStorage
> * BlockMatrixStorage
> * SplitCache
> * FeatureCache
> * ProjectionCache
> * SparseDistributedVectorStorage
> and others
> Also, all strategies of cache usage should be documented better (with 
> description of choosing one or another parameter value)



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

[jira] [Assigned] (IGNITE-6969) Move constants with influence on performance to separate config

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev reassigned IGNITE-6969:


Assignee: Aleksey Zinoviev

> Move constants with influence on performance to separate config
> ---
>
> Key: IGNITE-6969
> URL: https://issues.apache.org/jira/browse/IGNITE-6969
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Minor
>
> Move constants like BLOCK_SIZE in block matrix and block vector to a separate 
> config.
> Also a few constants in Decision Trees can be placed there.
> Motivation: Developer can tune this parameters to increase throughput.
> Comment: We need more detailed review to find other constants which can be 
> changed or override by developers. Please add them in comments



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

[jira] [Created] (IGNITE-6969) Move constants with influence on performance to separate config

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-6969:


 Summary: Move constants with influence on performance to separate 
config
 Key: IGNITE-6969
 URL: https://issues.apache.org/jira/browse/IGNITE-6969
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Priority: Minor


Move constants like BLOCK_SIZE in block matrix and block vector to a separate 
config.
Also a few constants in Decision Trees can be placed there.

Motivation: Developer can tune this parameters to increase throughput.

Comment: We need more detailed review to find other constants which can be 
changed or override by developers. Please add them in comments



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

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-4452:
---
Attachment: screenshot-1.png

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



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

[jira] [Created] (IGNITE-6968) Move similar Cache configurations in matrices and models to one Java or XML config

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-6968:


 Summary: Move similar Cache configurations in matrices and models 
to one Java or XML config
 Key: IGNITE-6968
 URL: https://issues.apache.org/jira/browse/IGNITE-6968
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev


There are a lot of copy-paste cache configs in matrices and vectors in method 
newCache() which returns configured cache for different data structures

For example
* SparseDistributedMatrixStorage
* BlockVectorStorage
* BlockMatrixStorage
* SplitCache
* FeatureCache
* ProjectionCache
* SparseDistributedVectorStorage
and others

Also, all strategies of cache usage should be documented better (with 
description of choosing one or another parameter value)




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

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4452:


Please fix
!screenshot-1.png!
To reproduce turn on Refresh rate

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



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

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-4452:
--

Assignee: Alexander Kalinin  (was: Pavel Konstantinov)

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



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

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

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-4454:
---

[~pkonstantinov] Added duration and node id in results header.

> 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: Alexander Kalinin
>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] [Assigned] (IGNITE-4454) Web console: add information on query panel UI about node query was executed on

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-4454:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

> 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] [Closed] (IGNITE-5296) Web console: Wrong queries list on clear of cookies

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-5296.
--

> Web console: Wrong queries list on clear of cookies
> ---
>
> Key: IGNITE-5296
> URL: https://issues.apache.org/jira/browse/IGNITE-5296
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>
> # Create several notebooks.
> # Clear all cookies
> # Refresh page and login.
> After login list of queries showed as empty. It is sowed after refresh.



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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-5641:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

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




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

[jira] [Commented] (IGNITE-5641) Web Console: In addition to export also implement copy result set to clipboard.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5641:


Tested. Can be merged into target branch.

> 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] [Comment Edited] (IGNITE-6872) Linear regression should implement Model API

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko edited comment on IGNITE-6872 at 11/21/17 7:11 AM:
--

Ready to merge: [pull request #3069|https://github.com/apache/ignite/pull/3069].

Compared to prior / draft implementation there are not many changes; 
IGNITE-5846 made impact only on code in example where I had to change local 
vector to distributed one (not surprising given that ticket 5846 involved 
improving consistency of "like" functionality of distributed matrices and 
vectors).

Teamcity run successfully: [build 
#952371|https://ci.ignite.apache.org/viewLog.html?buildId=952371=buildResultsDiv=Ignite20Tests_IgniteMl].
 Licenses and javadoc check also passed at Teamcity: [build 
#952678|https://ci.ignite.apache.org/viewLog.html?buildId=952678=queuedBuildOverviewTab].

[~chief], could you please take a look?


was (Author: oignatenko):
Ready to merge: [pull request #3069|https://github.com/apache/ignite/pull/3069].

Compared to prior / draft implementation there are not many changes; 
IGNITE-5846 made impact only on code in example where I had to change local 
vector to distributed one (not surprising given that ticket 5846 involved 
improving consistency of "like" functionality of distributed matrices and 
vectors).

Teamcity run successfully: [build 
#952371|https://ci.ignite.apache.org/viewLog.html?buildId=952371=buildResultsDiv=Ignite20Tests_IgniteMl].

[~chief], could you please take a look?

> Linear regression should implement Model API
> 
>
> Key: IGNITE-6872
> URL: https://issues.apache.org/jira/browse/IGNITE-6872
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> When linear regression was originally implemented per IGNITE-5012 we had no 
> Model API.
> Now that this API is available (merged into master with IGNITE-5218) lin 
> regression needs to adapt to implement it.



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

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

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-4394:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

Configured service for enabling garbage collection.

> 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
>  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] [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: Alexander Kalinin  (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: Alexander Kalinin
>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=16260345#comment-16260345
 ] 

Pavel Konstantinov commented on IGNITE-4454:


Tested, but I suggest to add the same info on panel above the table

> 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-4912) Fix testDeployCalledAfterCacheStart and testDeployCalledBeforeCacheStart tests

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin commented on IGNITE-4912:


Actually {{IgniteServiceDynamicCachesSelfTest#testDeployCalledAfterCacheStart}} 
doesn't fail in a few local runs.

> Fix testDeployCalledAfterCacheStart and testDeployCalledBeforeCacheStart tests
> --
>
> Key: IGNITE-4912
> URL: https://issues.apache.org/jira/browse/IGNITE-4912
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, general
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>
> IgniteServiceDynamicCachesSelfTest.testDeployCalledAfterCacheStart
> IgniteServiceDynamicCachesSelfTest.testDeployCalledBeforeCacheStart



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

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

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny reassigned IGNITE-6437:
--

Assignee: Semen Boikov  (was: Stanilovsky Evgeny)

> 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
>Assignee: Semen Boikov
>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] [Commented] (IGNITE-6437) DataStructure can not be obtained on client if it is created on server node.

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny commented on IGNITE-6437:


[~sboikov],
Test appended by me: testSrvReconnect is just little refactored 
NoQueueOnClientNodeTest.
Problem: if we create IgniteQueue on server node and after creation tries to 
access it by {code:java} queue = client.queue(queueName, 0, null) {code} we 
will fail.

> 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
>Assignee: Stanilovsky Evgeny
>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] [Comment Edited] (IGNITE-6437) DataStructure can not be obtained on client if it is created on server node.

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny edited comment on IGNITE-6437 at 11/21/17 6:39 AM:
--

[~sboikov],
Test appended by me: testSrvReconnect is just little refactored 
NoQueueOnClientNodeTest.
Problem: if we create IgniteQueue on server node and after creation tries to 
access it by {code:java} queue = client.queue(queueName, 0, null) {code} we 
will fail. Appended test failed before fix and ok after.


was (Author: zstan):
[~sboikov],
Test appended by me: testSrvReconnect is just little refactored 
NoQueueOnClientNodeTest.
Problem: if we create IgniteQueue on server node and after creation tries to 
access it by {code:java} queue = client.queue(queueName, 0, null) {code} we 
will fail.

> 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
>Assignee: Stanilovsky Evgeny
>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-6967) PME deadlock on reassigning service deployment

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-6967:
---
Description: 
With a service deployment when topology change occurs the discovery event 
listener calls {{GridServiceProcessor.reassign()}} causing to acquire a lock on 
utility cache (where the GridServiceAssignments stored) which prevents PME from 
completion.

Stack traces:

{noformat}
Thread [name="test-runner-#186%service.IgniteServiceDynamicCachesSelfTest%", 
id=232, state=WAITING, blockCnt=0, waitCnt=8]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at o.a.i.i.IgniteKernal.createCache(IgniteKernal.java:2841)
at 
o.a.i.i.processors.service.IgniteServiceDynamicCachesSelfTest.testDeployCalledBeforeCacheStart(IgniteServiceDynamicCachesSelfTest.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:748)

Thread [name="srvc-deploy-#38%service.IgniteServiceDynamicCachesSelfTest0%", 
id=56, state=WAITING, blockCnt=5, waitCnt=9]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
o.a.i.i.processors.cache.GridCacheContext.awaitStarted(GridCacheContext.java:443)
at 
o.a.i.i.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:373)
at 
o.a.i.i.processors.affinity.GridAffinityProcessor.keysToNodes(GridAffinityProcessor.java:347)
at 
o.a.i.i.processors.affinity.GridAffinityProcessor.mapKeyToNode(GridAffinityProcessor.java:259)
at 
o.a.i.i.processors.service.GridServiceProcessor.reassign(GridServiceProcessor.java:1163)
at 
o.a.i.i.processors.service.GridServiceProcessor.access$2400(GridServiceProcessor.java:123)
at 
o.a.i.i.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1763)
at 
o.a.i.i.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1976)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)

Locked synchronizers:
java.util.concurrent.ThreadPoolExecutor$Worker@27f723
{noformat}

Problematic code:
{noformat}
org.apache.ignite.internal.processors.service.GridServiceProcessor#reassign

try (GridNearTxLocal tx = cache.txStartEx(PESSIMISTIC, 
REPEATABLE_READ)) {
GridServiceAssignmentsKey key = new 
GridServiceAssignmentsKey(cfg.getName());

GridServiceAssignments oldAssigns = 
(GridServiceAssignments)cache.get(key);

Map cnts = new HashMap<>();

if (affKey != null) {
ClusterNode n = ctx.affinity().mapKeyToNode(cacheName, 
affKey, topVer);

// WAIT HERE UNTIL PME FINISHED (INFINITELY)
{noformat}

  was:
With a service deployment when topology change occurs the discovery event 
listener calls {{GridServiceProcessor.reassign()}} causing to acquire a lock on 
utility cache (where the GridServiceAssignments stored) which prevents PME from 
completion.

Stack traces:

{{noformat}}
Thread [name="test-runner-#186%service.IgniteServiceDynamicCachesSelfTest%", 
id=232, state=WAITING, blockCnt=0, waitCnt=8]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at o.a.i.i.IgniteKernal.createCache(IgniteKernal.java:2841)
at 

[jira] [Created] (IGNITE-6967) PME deadlock on reassigning service deployment

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-6967:
--

 Summary: PME deadlock on reassigning service deployment
 Key: IGNITE-6967
 URL: https://issues.apache.org/jira/browse/IGNITE-6967
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.3
Reporter: Alexandr Kuramshin


With a service deployment when topology change occurs the discovery event 
listener calls {{GridServiceProcessor.reassign()}} causing to acquire a lock on 
utility cache (where the GridServiceAssignments stored) which prevents PME from 
completion.

Stack traces:

{{noformat}}
Thread [name="test-runner-#186%service.IgniteServiceDynamicCachesSelfTest%", 
id=232, state=WAITING, blockCnt=0, waitCnt=8]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at o.a.i.i.IgniteKernal.createCache(IgniteKernal.java:2841)
at 
o.a.i.i.processors.service.IgniteServiceDynamicCachesSelfTest.testDeployCalledBeforeCacheStart(IgniteServiceDynamicCachesSelfTest.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
o.a.i.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:748)

Thread [name="srvc-deploy-#38%service.IgniteServiceDynamicCachesSelfTest0%", 
id=56, state=WAITING, blockCnt=5, waitCnt=9]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
o.a.i.i.processors.cache.GridCacheContext.awaitStarted(GridCacheContext.java:443)
at 
o.a.i.i.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:373)
at 
o.a.i.i.processors.affinity.GridAffinityProcessor.keysToNodes(GridAffinityProcessor.java:347)
at 
o.a.i.i.processors.affinity.GridAffinityProcessor.mapKeyToNode(GridAffinityProcessor.java:259)
at 
o.a.i.i.processors.service.GridServiceProcessor.reassign(GridServiceProcessor.java:1163)
at 
o.a.i.i.processors.service.GridServiceProcessor.access$2400(GridServiceProcessor.java:123)
at 
o.a.i.i.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1763)
at 
o.a.i.i.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1976)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)

Locked synchronizers:
java.util.concurrent.ThreadPoolExecutor$Worker@27f723
{{noformat}}

Problematic code:
{{noformat}}
org.apache.ignite.internal.processors.service.GridServiceProcessor#reassign

try (GridNearTxLocal tx = cache.txStartEx(PESSIMISTIC, 
REPEATABLE_READ)) {
GridServiceAssignmentsKey key = new 
GridServiceAssignmentsKey(cfg.getName());

GridServiceAssignments oldAssigns = 
(GridServiceAssignments)cache.get(key);

Map cnts = new HashMap<>();

if (affKey != null) {
ClusterNode n = ctx.affinity().mapKeyToNode(cacheName, 
affKey, topVer);

// WAIT HERE UNTIL PME FINISHED (INFINITELY)
{{noformat}}



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

[jira] [Commented] (IGNITE-5641) Web Console: In addition to export also implement copy result set to clipboard.

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-5641:
---

[~pkonstantinov] Implemented your suggestions. Please verify,

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

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-5641:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5641:


Place 'Copy to clipboard' as last item.
Add tooltip 'Copy current result page to clipboard'.

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-5641:
--

Assignee: Alexander Kalinin  (was: Pavel Konstantinov)

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




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

[jira] [Assigned] (IGNITE-6490) Optimize log search speed

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-6490:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Optimize log search speed
> -
>
> Key: IGNITE-6490
> URL: https://issues.apache.org/jira/browse/IGNITE-6490
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.4
>
>
> I see in VisorLogSearchJob code like this: `if 
> (s.toLowerCase().contains(searchStr))` and this is very non effective. This 
> can be reworked to `regionMatches` and this job should be profiled and may be 
> some other optimizations can be implemented.
> See similar issue on SO: 
> https://codereview.stackexchange.com/questions/44021/fast-way-of-searching-for-a-string-in-a-text-file



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

[jira] [Commented] (IGNITE-6490) Optimize log search speed

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6490:


Tested.

> Optimize log search speed
> -
>
> Key: IGNITE-6490
> URL: https://issues.apache.org/jira/browse/IGNITE-6490
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> I see in VisorLogSearchJob code like this: `if 
> (s.toLowerCase().contains(searchStr))` and this is very non effective. This 
> can be reworked to `regionMatches` and this job should be profiled and may be 
> some other optimizations can be implemented.
> See similar issue on SO: 
> https://codereview.stackexchange.com/questions/44021/fast-way-of-searching-for-a-string-in-a-text-file



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

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-5641:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

> 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-5296) Web console: Wrong queries list on clear of cookies

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5296:


Cannot reproduce. Closed.

> Web console: Wrong queries list on clear of cookies
> ---
>
> Key: IGNITE-5296
> URL: https://issues.apache.org/jira/browse/IGNITE-5296
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>
> # Create several notebooks.
> # Clear all cookies
> # Refresh page and login.
> After login list of queries showed as empty. It is sowed after refresh.



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

[jira] [Updated] (IGNITE-5296) Web console: Wrong queries list on clear of cookies

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-5296:
---
Description: 
# Create several notebooks.
# Clear all cookies
# Refresh page and login.

After login list of queries showed as empty. It is sowed after refresh.

  was:
# Create some several notebooks.
# Clear all cookies
# Refresh page and login.

After login list of queries showed as empty. It is sowed after refresh.


> Web console: Wrong queries list on clear of cookies
> ---
>
> Key: IGNITE-5296
> URL: https://issues.apache.org/jira/browse/IGNITE-5296
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>
> # Create several notebooks.
> # Clear all cookies
> # Refresh page and login.
> After login list of queries showed as empty. It is sowed after refresh.



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

[jira] [Updated] (IGNITE-5296) Web console: Wrong queries list on clear of cookies

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-5296:
---
Description: 
# Create some several notebooks.
# Clear all cookies
# Refresh page and login.

After login list of queries showed as empty. It is sowed after refresh.

  was:
# Create some queries lists.
# Clear all cookies
# Refresh page and login.

After login list of queries showed as empty. It is sowed after refresh.


> Web console: Wrong queries list on clear of cookies
> ---
>
> Key: IGNITE-5296
> URL: https://issues.apache.org/jira/browse/IGNITE-5296
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>
> # Create some several notebooks.
> # Clear all cookies
> # Refresh page and login.
> After login list of queries showed as empty. It is sowed after refresh.



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

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6914:


Tested. Can be merged into the target branch.

> 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
>
> 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] [Assigned] (IGNITE-6914) Web console: 'Export All' for scan stucks in Chrome but successfully finish in FireFox

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-6914:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> 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
>
> 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-6944) Fail to execute task with immutable list string

[Edmond Tsang (JIRA)]

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

Edmond Tsang commented on IGNITE-6944:
--

[~agura] by breaking 
[IGNITE-6485|https://issues.apache.org/jira/browse/IGNITE-6485] do you mean it 
would break the test case testWriteReplace() under 
org.apache.ignite.internal.binary.BinaryMarshallerSelfTest.java?

if so, it appears it is an issue in the test case. 

testWriteReplace() try serialize and deserialize the TestObject:
{code:java}
public void testWriteReplace() throws Exception {
BinaryMarshaller marsh = binaryMarshaller(Collections.singleton(
new BinaryTypeConfiguration(TestObject.class.getName())
));

TestObject obj = new TestObject();

BinaryObject po = marshal(obj, marsh);

assertEquals(obj, po.deserialize());

assertEquals(obj.val, ((BinaryObject)po.field("val")).deserialize());
}
{code}

TestObject has variable val of type Intf:
{code:java}
static class TestObject {
/** Value. */
Intf val = new IntfImpl();

/** {@inheritDoc} */
@Override public boolean equals(Object o) {
if (this == o)
return true;
if (o == null || getClass() != o.getClass())
return false;

TestObject obj = (TestObject)o;

return val.equals(obj.val);
}
}
{code}

IntfImpl extends Cls and implement Intf:
{code:java}
static class IntfImpl extends Cls implements Intf {
/** {@inheritDoc} */
@Override public long value() {
return longValue();
}
}
{code}

Method readResolve() from SerializationProxy return val from Cls object, 
however Cls doesn't implement IntfImpl which causes the issue:
{code:java}
static class Cls implements Serializable {
/** Value. */
long val;

/** */
public long longValue() {
return val;
}

/** {@inheritDoc} */
@Override public boolean equals(Object o) {
if (this == o)
return true;
if (o == null || getClass() != o.getClass())
return false;

Cls cls = (Cls)o;

return val == cls.val;
}

/** */
private Object writeReplace() {
return new SerializationProxy(this);
}

/** */
private static class SerializationProxy implements Serializable {
/** Value. */
private final long val;

/** */
SerializationProxy(Cls a) {
val = a.longValue();
}

/** */
private Object readResolve() {
Cls a = new Cls();

a.val = val;

return a;
}
}
}
{code}

Changing the readResolve method to return val from IntfImpl object can fix the 
issue:
{code:java}
private Object readResolve() {
IntfImpl a = new IntfImpl();

a.val = val;

return a;
}
{code}






> Fail to execute task with immutable list string
> ---
>
> Key: IGNITE-6944
> URL: https://issues.apache.org/jira/browse/IGNITE-6944
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.3
>Reporter: Edmond Tsang
> Attachments: BinaryMarshellerWithGuavaSelfTest.java, 
> TestClientWithGuava.java
>
>
> Exception occurs when executing task with immutable list of string due to not 
> able to find method readResolve/writeReplace for binary object.
> It appears this is caused by a side effect of Jira 
> https://issues.apache.org/jira/browse/IGNITE-6485 



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

[jira] [Commented] (IGNITE-5641) Web Console: In addition to export also implement copy result set to clipboard.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5641:


I didn't find the result in the branch ignite-5641. Please verify from your 
side.

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-5641:
--

Assignee: Alexander Kalinin  (was: Pavel Konstantinov)

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




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

[jira] [Comment Edited] (IGNITE-6745) Java 9: rework usages of URLClassLoader.getURLs()

[Cergey Chaulin (JIRA)]

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

Cergey Chaulin edited comment on IGNITE-6745 at 11/20/17 11:49 PM:
---

1. The file is present in the patch. I'll add it to the pull request. 
.. Other points will be fixed.

These changes only refer to runtime (i.e. when running under jdk-9 and to run 
as such appropriate modules should be supplied as "-add-opens" etc. in command 
line, probably we need tests for this also). To build under jdk-9 all the 
issues in IGNITE-6728 should be fixed.


was (Author: cossack5):
1. The file is present in the patch. I'll add it to the pull request. 
.. Other points will be fixed.

These changes only refer to runtime (running under jdk-9 - to run corresponding 
"--add-opens" modules should be supplied in command line, probably we need 
tests for this also). To build under jdk-9 all the issues in IGNITE-6728 should 
be fixed.

> Java 9: rework usages of URLClassLoader.getURLs()
> -
>
> Key: IGNITE-6745
> URL: https://issues.apache.org/jira/browse/IGNITE-6745
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
> Fix For: 2.4
>
> Attachments: IGNITE-6745.patch
>
>
> We use this method in multiple places:
> 1) {{MessageCodeGenerator}}
> 2) {{BinaryContext}}
> 3) {{ClassesGenerator}}
> 4) {{GridUriDeploymentFileProcessor}}
> The problem is that in Java 9 application class loader is not 
> {{URLClassLoader}}, so we cannot get URLs easily. Instead typically it is 
> {{BuiltinClassLoader}}, which refers to {{URLClassLoader}} in it's internal 
> field {{ucp}}.
> Let's refactor all usages of {{URLClassLoader.getURLs}} to some utility 
> method, which will be able to handle both Java 7/8 and Java 9 (through 
> reflection).



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6966:

Labels: iep-6  (was: )

> 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] [Created] (IGNITE-6966) Average time metrics are not calculated for client driven operations

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6966:
---

 Summary: 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
 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] [Comment Edited] (IGNITE-6745) Java 9: rework usages of URLClassLoader.getURLs()

[Cergey Chaulin (JIRA)]

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

Cergey Chaulin edited comment on IGNITE-6745 at 11/20/17 9:52 PM:
--

1. The file is present in the patch. I'll add it to the pull request. 
.. Other points will be fixed.

These changes only refer to runtime (running under jdk-9 - to run corresponding 
"--add-opens" modules should be supplied in command line, probably we need 
tests for this also). To build under jdk-9 all the issues in IGNITE-6728 should 
be fixed.


was (Author: cossack5):
1. The file is present in the patch. I'll add it to the pull request. 
.. Other issues will be fixed.

These changes only refer to runtime (running under jdk-9). To build under jdk-9 
all the issues in IGNITE-6728 should be fixed. 

> Java 9: rework usages of URLClassLoader.getURLs()
> -
>
> Key: IGNITE-6745
> URL: https://issues.apache.org/jira/browse/IGNITE-6745
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
> Fix For: 2.4
>
> Attachments: IGNITE-6745.patch
>
>
> We use this method in multiple places:
> 1) {{MessageCodeGenerator}}
> 2) {{BinaryContext}}
> 3) {{ClassesGenerator}}
> 4) {{GridUriDeploymentFileProcessor}}
> The problem is that in Java 9 application class loader is not 
> {{URLClassLoader}}, so we cannot get URLs easily. Instead typically it is 
> {{BuiltinClassLoader}}, which refers to {{URLClassLoader}} in it's internal 
> field {{ucp}}.
> Let's refactor all usages of {{URLClassLoader.getURLs}} to some utility 
> method, which will be able to handle both Java 7/8 and Java 9 (through 
> reflection).



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

[jira] [Commented] (IGNITE-6745) Java 9: rework usages of URLClassLoader.getURLs()

[Cergey Chaulin (JIRA)]

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

Cergey Chaulin commented on IGNITE-6745:


1. The file is present in the patch. I'll add it to the pull request. 
.. Other issues will be fixed.

These changes only refer to runtime (running under jdk-9). To build under jdk-9 
all the issues in IGNITE-6728 should be fixed. 

> Java 9: rework usages of URLClassLoader.getURLs()
> -
>
> Key: IGNITE-6745
> URL: https://issues.apache.org/jira/browse/IGNITE-6745
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Vladimir Ozerov
> Fix For: 2.4
>
> Attachments: IGNITE-6745.patch
>
>
> We use this method in multiple places:
> 1) {{MessageCodeGenerator}}
> 2) {{BinaryContext}}
> 3) {{ClassesGenerator}}
> 4) {{GridUriDeploymentFileProcessor}}
> The problem is that in Java 9 application class loader is not 
> {{URLClassLoader}}, so we cannot get URLs easily. Instead typically it is 
> {{BuiltinClassLoader}}, which refers to {{URLClassLoader}} in it's internal 
> field {{ucp}}.
> Let's refactor all usages of {{URLClassLoader.getURLs}} to some utility 
> method, which will be able to handle both Java 7/8 and Java 9 (through 
> reflection).



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

[jira] [Commented] (IGNITE-6696) Update loading and streaming page on the site

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6696:
-

Reviewed and merged.

> Update loading and streaming page on the site
> -
>
> Key: IGNITE-6696
> URL: https://issues.apache.org/jira/browse/IGNITE-6696
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> The pages below incorporate table with streaming and loading features of 
> Ignite:
> * https://ignite.apache.org/features/streaming.html
> * https://ignite.apache.org/features.html
> Update them with the content for the following:
> * Data Loading: https://apacheignite.readme.io/docs/data-loading
> * Flink: https://apacheignite-mix.readme.io/docs/flink-streamer
> * ZeroMQ: https://apacheignite-mix.readme.io/docs/zeromq-streamer
> * RocketMQ: https://apacheignite-mix.readme.io/docs/rocketmq-streamer



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

[jira] [Resolved] (IGNITE-6696) Update loading and streaming page on the site

[Prachi Garg (JIRA)]

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

Prachi Garg resolved IGNITE-6696.
-
Resolution: Fixed

Done.

> Update loading and streaming page on the site
> -
>
> Key: IGNITE-6696
> URL: https://issues.apache.org/jira/browse/IGNITE-6696
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> The pages below incorporate table with streaming and loading features of 
> Ignite:
> * https://ignite.apache.org/features/streaming.html
> * https://ignite.apache.org/features.html
> Update them with the content for the following:
> * Data Loading: https://apacheignite.readme.io/docs/data-loading
> * Flink: https://apacheignite-mix.readme.io/docs/flink-streamer
> * ZeroMQ: https://apacheignite-mix.readme.io/docs/zeromq-streamer
> * RocketMQ: https://apacheignite-mix.readme.io/docs/rocketmq-streamer



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

[jira] [Closed] (IGNITE-6696) Update loading and streaming page on the site

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-6696.
---

> Update loading and streaming page on the site
> -
>
> Key: IGNITE-6696
> URL: https://issues.apache.org/jira/browse/IGNITE-6696
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> The pages below incorporate table with streaming and loading features of 
> Ignite:
> * https://ignite.apache.org/features/streaming.html
> * https://ignite.apache.org/features.html
> Update them with the content for the following:
> * Data Loading: https://apacheignite.readme.io/docs/data-loading
> * Flink: https://apacheignite-mix.readme.io/docs/flink-streamer
> * ZeroMQ: https://apacheignite-mix.readme.io/docs/zeromq-streamer
> * RocketMQ: https://apacheignite-mix.readme.io/docs/rocketmq-streamer



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

[jira] [Updated] (IGNITE-6965) affinityCall() with key mapping may not be successful with AlwaysFailoverSpi when node left

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-6965:
---
Attachment: 
IGNITE_6965_affinityCall_with_key_mapping_AlwaysFailoverSpi_node_left.patch

Run test CacheAffinityCallSelfTest.testAffinityCallFromClientRestartNode()

> affinityCall() with key mapping may not be successful with AlwaysFailoverSpi 
> when node left
> ---
>
> Key: IGNITE-6965
> URL: https://issues.apache.org/jira/browse/IGNITE-6965
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, compute
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
> Attachments: 
> IGNITE_6965_affinityCall_with_key_mapping_AlwaysFailoverSpi_node_left.patch
>
>
> When doing {{affinityCall(cacheName, key, callable)}} there is a race between 
> affinity node left then stopped and {{AlwaysFailoverSpi}} max attempts 
> reached.
> Suppose the following sequence (more probable when {{grid2.order}} >> 
> {{grid1.order}}):
> 1. {{grid1.affinityCall(cacheName, key, callable)}}
> 2. {{grid1}}: {{key}} mapped to the primary partition on {{grid2}}
> 3. {{grid2.stop()}}
> 4. {{grid1}} receives {{NODE_LEFT}} and updates {{discoCache}}
> 5. {{grid1}} execution {{callable}} failed with 'Failed to send job request 
> because remote node left grid (if fail-over is enabled, will attempt 
> fail-over to another node'
> 6. {{grid1}}: {{AlwaysFailoverSpi}} max attempts reached.
> 7. {{grid1.affinityCall}} failed with 'Job failover failed because number of 
> maximum failover attempts for affinity call is exceeded'
> 8. {{grid2}} receives verified node left message then stopping.
> The patched {{CacheAffinityCallSelfTest}} reproduces the problem.



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

[jira] [Updated] (IGNITE-6965) affinityCall() with key mapping may not be successful with AlwaysFailoverSpi when node left

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-6965:
---
Attachment: (was: 
IGNITE_6965_affinityCall_with_key_mapping_AlwaysFailoverSpi_node_left.patch)

> affinityCall() with key mapping may not be successful with AlwaysFailoverSpi 
> when node left
> ---
>
> Key: IGNITE-6965
> URL: https://issues.apache.org/jira/browse/IGNITE-6965
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, compute
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
> Attachments: 
> IGNITE_6965_affinityCall_with_key_mapping_AlwaysFailoverSpi_node_left.patch
>
>
> When doing {{affinityCall(cacheName, key, callable)}} there is a race between 
> affinity node left then stopped and {{AlwaysFailoverSpi}} max attempts 
> reached.
> Suppose the following sequence (more probable when {{grid2.order}} >> 
> {{grid1.order}}):
> 1. {{grid1.affinityCall(cacheName, key, callable)}}
> 2. {{grid1}}: {{key}} mapped to the primary partition on {{grid2}}
> 3. {{grid2.stop()}}
> 4. {{grid1}} receives {{NODE_LEFT}} and updates {{discoCache}}
> 5. {{grid1}} execution {{callable}} failed with 'Failed to send job request 
> because remote node left grid (if fail-over is enabled, will attempt 
> fail-over to another node'
> 6. {{grid1}}: {{AlwaysFailoverSpi}} max attempts reached.
> 7. {{grid1.affinityCall}} failed with 'Job failover failed because number of 
> maximum failover attempts for affinity call is exceeded'
> 8. {{grid2}} receives verified node left message then stopping.
> The patched {{CacheAffinityCallSelfTest}} reproduces the problem.



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

[jira] [Updated] (IGNITE-6965) affinityCall() with key mapping may not be successful with AlwaysFailoverSpi when node left

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-6965:
---
Attachment: 
IGNITE_6965_affinityCall_with_key_mapping_AlwaysFailoverSpi_node_left.patch

> affinityCall() with key mapping may not be successful with AlwaysFailoverSpi 
> when node left
> ---
>
> Key: IGNITE-6965
> URL: https://issues.apache.org/jira/browse/IGNITE-6965
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, compute
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
> Attachments: 
> IGNITE_6965_affinityCall_with_key_mapping_AlwaysFailoverSpi_node_left.patch
>
>
> When doing {{affinityCall(cacheName, key, callable)}} there is a race between 
> affinity node left then stopped and {{AlwaysFailoverSpi}} max attempts 
> reached.
> Suppose the following sequence (more probable when {{grid2.order}} >> 
> {{grid1.order}}):
> 1. {{grid1.affinityCall(cacheName, key, callable)}}
> 2. {{grid1}}: {{key}} mapped to the primary partition on {{grid2}}
> 3. {{grid2.stop()}}
> 4. {{grid1}} receives {{NODE_LEFT}} and updates {{discoCache}}
> 5. {{grid1}} execution {{callable}} failed with 'Failed to send job request 
> because remote node left grid (if fail-over is enabled, will attempt 
> fail-over to another node'
> 6. {{grid1}}: {{AlwaysFailoverSpi}} max attempts reached.
> 7. {{grid1.affinityCall}} failed with 'Job failover failed because number of 
> maximum failover attempts for affinity call is exceeded'
> 8. {{grid2}} receives verified node left message then stopping.
> The patched {{CacheAffinityCallSelfTest}} reproduces the problem.



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

[jira] [Created] (IGNITE-6965) affinityCall() with key mapping may not be successful with AlwaysFailoverSpi when node left

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-6965:
--

 Summary: affinityCall() with key mapping may not be successful 
with AlwaysFailoverSpi when node left
 Key: IGNITE-6965
 URL: https://issues.apache.org/jira/browse/IGNITE-6965
 Project: Ignite
  Issue Type: Bug
  Components: cache, compute
Affects Versions: 2.3
Reporter: Alexandr Kuramshin


When doing {{affinityCall(cacheName, key, callable)}} there is a race between 
affinity node left then stopped and {{AlwaysFailoverSpi}} max attempts reached.

Suppose the following sequence (more probable when {{grid2.order}} >> 
{{grid1.order}}):

1. {{grid1.affinityCall(cacheName, key, callable)}}
2. {{grid1}}: {{key}} mapped to the primary partition on {{grid2}}
3. {{grid2.stop()}}
4. {{grid1}} receives {{NODE_LEFT}} and updates {{discoCache}}
5. {{grid1}} execution {{callable}} failed with 'Failed to send job request 
because remote node left grid (if fail-over is enabled, will attempt fail-over 
to another node'
6. {{grid1}}: {{AlwaysFailoverSpi}} max attempts reached.
7. {{grid1.affinityCall}} failed with 'Job failover failed because number of 
maximum failover attempts for affinity call is exceeded'
8. {{grid2}} receives verified node left message then stopping.

The patched {{CacheAffinityCallSelfTest}} reproduces the problem.



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6846:

Priority: Critical  (was: Major)

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



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6903:

Priority: Critical  (was: Major)

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



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

[jira] [Closed] (IGNITE-6673) Document write throttling

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-6673.
---

Done.

> Document write throttling
> -
>
> Key: IGNITE-6673
> URL: https://issues.apache.org/jira/browse/IGNITE-6673
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Reporter: Alexey Goncharuk
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.4
>
>
> We need to document changes made in the ticket IGNITE-6334



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6963:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-6963: Made PhysicalMemoryPages equal to TotalAllocatedPages when PDS 
is off



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-6963

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

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


commit e5d412392c2d7d3e8310f2a7772db8fc104efac0
Author: Andrey Kuznetsov 
Date:   2017-11-20T17:35:14Z

IGNITE-6963: Made PhysicalMemoryPages equal to TotalAllocatedPages when PDS 
is off.




> 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
>
> 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-6876) ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6876:


Github user isapego closed the pull request at:

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


> ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT
> -
>
> Key: IGNITE-6876
> URL: https://issues.apache.org/jira/browse/IGNITE-6876
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> Remote ODBC client should be able to request a timeout for socket 
> send/receive operations. It should be done with 
> {{SQL_ATTR_CONNECTION_TIMEOUT}} attribute.
> If an application with ODBC driver experiences a timeout for some query, it 
> can continue to work after closing the connection and establishing a new one.



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

[jira] [Commented] (IGNITE-6876) ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-6876:
-

Thanks guys, everything fixed.

> ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT
> -
>
> Key: IGNITE-6876
> URL: https://issues.apache.org/jira/browse/IGNITE-6876
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> Remote ODBC client should be able to request a timeout for socket 
> send/receive operations. It should be done with 
> {{SQL_ATTR_CONNECTION_TIMEOUT}} attribute.
> If an application with ODBC driver experiences a timeout for some query, it 
> can continue to work after closing the connection and establishing a new one.



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

[jira] [Created] (IGNITE-6964) Ignite restart with PDS enabled may cause delays in TTL cleanup worker

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-6964:
--

 Summary: 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-6876) ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-6876:


@Igor Sapego, I only have 2 minor comments to add:
1. SocketClient::TrySetOptions(), the case when setting non-blocking mode has 
failed.
Can you extend the message you put to diagnostic record with a remark that 
connection timeout functionality will not work because of that?

2. File attributes_test.cpp. 
Misprint in the name of the test 
BOOST_AUTO_TEST_CASE(ConnetionAttributeConnectionTimeout)

Otherwise, looks good to me. Thanks.


> ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT
> -
>
> Key: IGNITE-6876
> URL: https://issues.apache.org/jira/browse/IGNITE-6876
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> Remote ODBC client should be able to request a timeout for socket 
> send/receive operations. It should be done with 
> {{SQL_ATTR_CONNECTION_TIMEOUT}} attribute.
> If an application with ODBC driver experiences a timeout for some query, it 
> can continue to work after closing the connection and establishing a new one.



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

[jira] [Assigned] (IGNITE-6948) SQL: Document new INLINE_SIZE option in CREATE INDEX command

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov reassigned IGNITE-6948:
---

Assignee: Denis Magda  (was: Kirill Shirokov)

> SQL: Document new INLINE_SIZE option in CREATE INDEX command
> 
>
> Key: IGNITE-6948
> URL: https://issues.apache.org/jira/browse/IGNITE-6948
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Kirill Shirokov
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> INLINE_SIZE is optional and accepts positive integer values. To specify the 
> default inline size user should omit the option.
> The corresponding documentation page is at:
> https://apacheignite-sql.readme.io/docs/create-index



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

[jira] [Comment Edited] (IGNITE-6948) SQL: Document new INLINE_SIZE option in CREATE INDEX command

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov edited comment on IGNITE-6948 at 11/20/17 4:26 PM:
---

[~dmagda], I've updated the hidden page. Could you please take a look at it? 
Please return the ticket if the page needs to fixed.


was (Author: kirill.shirokov):
I've updated the hidden page. Could you please take a look at it? Please return 
the ticket if the page needs to fixed.

> SQL: Document new INLINE_SIZE option in CREATE INDEX command
> 
>
> Key: IGNITE-6948
> URL: https://issues.apache.org/jira/browse/IGNITE-6948
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
> Fix For: 2.4
>
>
> INLINE_SIZE is optional and accepts positive integer values. To specify the 
> default inline size user should omit the option.
> The corresponding documentation page is at:
> https://apacheignite-sql.readme.io/docs/create-index



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

[jira] [Commented] (IGNITE-6948) SQL: Document new INLINE_SIZE option in CREATE INDEX command

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov commented on IGNITE-6948:
-

I've updated the hidden page. Could you please take a look at it? Please return 
the ticket if the page needs to fixed.

> SQL: Document new INLINE_SIZE option in CREATE INDEX command
> 
>
> Key: IGNITE-6948
> URL: https://issues.apache.org/jira/browse/IGNITE-6948
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Kirill Shirokov
>Assignee: Kirill Shirokov
> Fix For: 2.4
>
>
> INLINE_SIZE is optional and accepts positive integer values. To specify the 
> default inline size user should omit the option.
> The corresponding documentation page is at:
> https://apacheignite-sql.readme.io/docs/create-index



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

[jira] [Commented] (IGNITE-6959) Split a ttl index tree by partition

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6959:


I suppose it is now supported in per cache manner, but still this change seems 
to be useful to reduce TTL entries tree update completixy.

> Split a ttl index tree by partition  
> -
>
> Key: IGNITE-6959
> URL: https://issues.apache.org/jira/browse/IGNITE-6959
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Alexey Goncharuk
>Priority: Minor
>
> Now a tree to trace an entries' TTL presented only one per a node. To improve 
> a performance need to split the tree per partition. 



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

[jira] [Commented] (IGNITE-6876) ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6876:


[~isapego] looks good to me in general.
I would add some explanation to {{WaitOnSocket}} code - how it uses {{select}} 
in non-blocking mode to achieve timeout functionality.
Also please fix magic numbers in there ({{if (ready == 0) return 0; return 
1;}}).


> ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT
> -
>
> Key: IGNITE-6876
> URL: https://issues.apache.org/jira/browse/IGNITE-6876
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> Remote ODBC client should be able to request a timeout for socket 
> send/receive operations. It should be done with 
> {{SQL_ATTR_CONNECTION_TIMEOUT}} attribute.
> If an application with ODBC driver experiences a timeout for some query, it 
> can continue to work after closing the connection and establishing a new one.



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

[jira] [Comment Edited] (IGNITE-6784) Document cluster activation via REST protocol

[Prachi Garg (JIRA)]

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

Prachi Garg edited comment on IGNITE-6784 at 11/20/17 4:14 PM:
---

Commented in ticket - https://issues.apache.org/jira/browse/IGNITE-5733 to fix 
the commands before it can be documented.


was (Author: pgarg):
Commented in ticket - https://issues.apache.org/jira/browse/IGNITE-5733 to fix 
the commands, before it can be documented.

> Document cluster activation via REST protocol
> -
>
> Key: IGNITE-6784
> URL: https://issues.apache.org/jira/browse/IGNITE-6784
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 2.4
>
>
> Starting Ignite 2.3 cluster can be activated with REST protocol. The 
> following commands are supported:
> - {{activate}} - actives the cluster.
> - {{deactivate}} - deactivates the cluster.
> - {{currentstate}} - checks current cluster state.
> Update both pages below:
> https://apacheignite.readme.io/docs/rest-api
> https://apacheignite.readme.io/v2.2/docs/cluster-activation



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

[jira] [Comment Edited] (IGNITE-6872) Linear regression should implement Model API

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko edited comment on IGNITE-6872 at 11/20/17 4:12 PM:
--

Ready to merge: [pull request #3069|https://github.com/apache/ignite/pull/3069].

Compared to prior / draft implementation there are not many changes; 
IGNITE-5846 made impact only on code in example where I had to change local 
vector to distributed one (not surprising given that ticket 5846 involved 
improving consistency of "like" functionality of distributed matrices and 
vectors).

Teamcity run successfully: [build 
#952371|https://ci.ignite.apache.org/viewLog.html?buildId=952371=buildResultsDiv=Ignite20Tests_IgniteMl].

[~chief], could you please take a look?


was (Author: oignatenko):
Ready to merge: [pull request #3069|https://github.com/apache/ignite/pull/3069].

Compared to prior / draft implementation there are not many changes; 
IGNITE-5846 made impact only on code in example where I had to change local 
vector to distributed one (not surprising given that ticket 5846 involved 
improving consistency of "like" functionality of distributed matrices and 
vectors).

[~chief], could you please take a look?

> Linear regression should implement Model API
> 
>
> Key: IGNITE-6872
> URL: https://issues.apache.org/jira/browse/IGNITE-6872
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> When linear regression was originally implemented per IGNITE-5012 we had no 
> Model API.
> Now that this API is available (merged into master with IGNITE-5218) lin 
> regression needs to adapt to implement it.



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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-6963:


Assignee: Andrey Kuznetsov

> 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
>
> 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] [Created] (IGNITE-6963) TotalAllocatedPages metric does not match PhysicalMemoryPages when persistence is disabled

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-6963:


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


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] [Updated] (IGNITE-6961) Internal Problems should be covered by Monitoring tool

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6961:
-
Labels: iep-7  (was: ie7)

> Internal Problems should be covered by Monitoring tool
> --
>
> Key: IGNITE-6961
> URL: https://issues.apache.org/jira/browse/IGNITE-6961
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Alexey Kuznetsov
>  Labels: iep-7
>
> - Monitoring tool should provide UI which allows to view and manage:
>   - active transactions (including: long-running)  (IGNITE-6894)
>   - locks aquired;
>   - tasks performed; (IGNITE-6869)
>   - deadlocks detected. (IGNITE-6895)
>   
> - Moniroring tool should alert and keeps history of:
>   - java level deadlocks; (IGNITE-6893)
>   - GC- or STW- pauses; (IGNITE-6171)
>   - threadpool starvation events. (IGNITE-6940)
> Best candidates (as monitoring tool) are WebConsole and VisorConsole



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

[jira] [Commented] (IGNITE-6818) In case of incoming communication connection ping the old one if it's alive

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6818:


Github user alamar closed the pull request at:

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


> In case of incoming communication connection ping the old one if it's alive
> ---
>
> Key: IGNITE-6818
> URL: https://issues.apache.org/jira/browse/IGNITE-6818
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Critical
> Fix For: 2.4
>
>
> Assume the following scenario:
> 1. Client opens connection to the server.
> 2. Server checks that it is a first connection to that node and accepts it.
> 3. By some reason firewall starts rejecting client messages with TCP reset 
> flag set.
> 4. Client closes connection, but server doesn't know about it.
> 5. Client tries connect again.
> 6. Server rejects new connection, because it already has connection to that 
> node.
> Possible fix: on step 6 server must check old connection if it's alive by 
> sending some communication message and check response. If old connection is 
> dead - close it and accept new one.



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

[jira] [Commented] (IGNITE-4003) Slow or faulty client can stall the whole cluster.

[Amit Pundir (JIRA)]

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

Amit Pundir commented on IGNITE-4003:
-

Please update for the status of this bug fix.

> Slow or faulty client can stall the whole cluster.
> --
>
> Key: IGNITE-4003
> URL: https://issues.apache.org/jira/browse/IGNITE-4003
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
>Priority: Critical
>
> Steps to reproduce:
> 1) Start two server nodes and some data to cache.
> 2) Start a client from Docker subnet, which is not visible from the outside. 
> Client will join the cluster.
> 3) Try to put something to cache or start another node to force rabalance.
> Cluster is stuck at this moment. Root cause - servers are constantly trying 
> to establish outgoing connection to the client, but fail as Docker subnet is 
> not visible from the outside. It may stop virtually all cluster operations.
> Typical thread dump:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to send message (node may 
> have left the grid or TCP connection cannot be established due to firewall 
> issues) [node=TcpDiscoveryNode [id=a15d74c2-1ec2-4349-9640-aeacd70d8714, 
> addrs=[127.0.0.1, 172.17.0.6], sockAddrs=[/127.0.0.1:0, /127.0.0.1:0, 
> /172.17.0.6:0], discPort=0, order=7241, intOrder=3707, 
> lastExchangeTime=1474096941045, loc=false, ver=1.5.23#20160526-sha1:259146da, 
> isClient=true], topic=T4 [topic=TOPIC_CACHE, 
> id1=949732fd-1360-3a58-8d9e-0ff6ea6182cc, 
> id2=a15d74c2-1ec2-4349-9640-aeacd70d8714, id3=2], msg=GridContinuousMessage 
> [type=MSG_EVT_NOTIFICATION, routineId=7e13c48e-6933-48b2-9f15-8d92007930db, 
> data=null, futId=null], policy=2]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1347)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1227)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1198)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1180)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:841)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:800)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:787)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3476)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:548)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:207)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.processForceKeyResponse(GridDhtPreloader.java:636)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.access$1000(GridDhtPreloader.java:81)
>  

[jira] [Resolved] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov resolved IGNITE-5195.
--
Resolution: Fixed

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Mikhail Cherkasov
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5195:
--

[~mcherkas],
Thank you for your contribution! Looks good for me. Merged to master.

> DataStreamer can fails if non-data node enter\leave the grid.
> -
>
> Key: IGNITE-5195
> URL: https://issues.apache.org/jira/browse/IGNITE-5195
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Mikhail Cherkasov
> Fix For: 2.4
>
> Attachments: DataStreamerFailure.java
>
>
> DataStreamer failed with "too many remaps" message even if non-data node 
> enter\leave topology.
> PFA repro attached. 
> Seems, we should ignore topology changes when non-data node enter\leave the 
> grid. 
> And also we need to sure that remapping doesn't occurs when there is no data 
> nodes in grid any more, as remapping make no sense and more suitable message 
> should be logged.



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6711:
--

Even when I start with persistence enabled on empty db I still see strange 
values, e.g.

{noformat}
PhysycalMemoryPages = 4610
TotalAllocatedPages = 4063
{noformat}



> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Issue Comment Deleted] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6711:
-
Comment: was deleted

(was: Derived metric will be incorrect as well)

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-6711:
--

Derived metric will be incorrect as well

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>  Labels: newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Created] (IGNITE-6962) Reduce ExchangeHistory memory consumption

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-6962:


 Summary: Reduce ExchangeHistory memory consumption
 Key: IGNITE-6962
 URL: https://issues.apache.org/jira/browse/IGNITE-6962
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexander Belyak


GridDhtPartitionExchangeManager$ExhcangeFutureSet store huge message 
GridDhtPartitionsFullMessage with IgniteDhtPartitionCountersMap2 for each cache 
group with two long[partCount]. If we have big grid (100+ nodes) with large 
amount of cacheGroups and partitions in CachePartitionFullCountersMap(long[] 
initialUpdCntrs; long[] updCntrs;)
*<2 

[jira] [Updated] (IGNITE-6961) Internal Problems should be covered by Monitoring tool

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6961:
-
Description: 
- Monitoring tool should provide UI which allows to view and manage:
- active transactions (including: long-running)  (IGNITE-6894)
- locks aquired;
- tasks performed; (IGNITE-6869)
- deadlocks detected. (IGNITE-6895)

- Moniroring tool should alert and keeps history of:
- java level deadlocks; (IGNITE-6893)
- GC- or STW- pauses; (IGNITE-6171)
- threadpool starvation events. (IGNITE-6940)

Best candidates (as monitoring tool) are WebConsole and VisorConsole

  was:
- Monitoring tool should provide UI which allows to view and manage:
- active transactions (including: long-running) 
- locks aquired;
- tasks performed;
- deadlocks detected.

- Moniroring tool should alert and keeps history of:
- java level deadlocks;
- GC- or STW- pauses;
- threadpool starvation events.

Best candidates (as monitoring tool) are WebConsole and VisorConsole


> Internal Problems should be covered by Monitoring tool
> --
>
> Key: IGNITE-6961
> URL: https://issues.apache.org/jira/browse/IGNITE-6961
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Alexey Kuznetsov
>  Labels: ie7
>
> - Monitoring tool should provide UI which allows to view and manage:
>   - active transactions (including: long-running)  (IGNITE-6894)
>   - locks aquired;
>   - tasks performed; (IGNITE-6869)
>   - deadlocks detected. (IGNITE-6895)
>   
> - Moniroring tool should alert and keeps history of:
>   - java level deadlocks; (IGNITE-6893)
>   - GC- or STW- pauses; (IGNITE-6171)
>   - threadpool starvation events. (IGNITE-6940)
> Best candidates (as monitoring tool) are WebConsole and VisorConsole



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

[jira] [Updated] (IGNITE-6961) Internal Problems should be covered by Monitoring tool

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6961:
-
Labels: ie7  (was: )

> Internal Problems should be covered by Monitoring tool
> --
>
> Key: IGNITE-6961
> URL: https://issues.apache.org/jira/browse/IGNITE-6961
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Assignee: Alexey Kuznetsov
>  Labels: ie7
>
> - Monitoring tool should provide UI which allows to view and manage:
>   - active transactions (including: long-running) 
>   - locks aquired;
>   - tasks performed;
>   - deadlocks detected.
>   
> - Moniroring tool should alert and keeps history of:
>   - java level deadlocks;
>   - GC- or STW- pauses;
>   - threadpool starvation events.
> Best candidates (as monitoring tool) are WebConsole and VisorConsole



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

[jira] [Commented] (IGNITE-6872) Linear regression should implement Model API

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-6872:


Ready to merge: [pull request #3069|https://github.com/apache/ignite/pull/3069].

Compared to prior / draft implementation there are not many changes; 
IGNITE-5846 made impact only on code in example where I had to change local 
vector to distributed one (not surprising given that ticket 5846 involved 
improving consistency of "like" functionality of distributed matrices and 
vectors).

[~chief], could you please take a look?

> Linear regression should implement Model API
> 
>
> Key: IGNITE-6872
> URL: https://issues.apache.org/jira/browse/IGNITE-6872
> Project: Ignite
>  Issue Type: Task
>  Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
> Fix For: 2.4
>
>
> When linear regression was originally implemented per IGNITE-5012 we had no 
> Model API.
> Now that this API is available (merged into master with IGNITE-5218) lin 
> regression needs to adapt to implement it.



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

[jira] [Created] (IGNITE-6961) Internal Problems should be covered by Monitoring tool

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-6961:


 Summary: Internal Problems should be covered by Monitoring tool
 Key: IGNITE-6961
 URL: https://issues.apache.org/jira/browse/IGNITE-6961
 Project: Ignite
  Issue Type: New Feature
Reporter: Anton Vinogradov
Assignee: Alexey Kuznetsov


- Monitoring tool should provide UI which allows to view and manage:
- active transactions (including: long-running) 
- locks aquired;
- tasks performed;
- deadlocks detected.

- Moniroring tool should alert and keeps history of:
- java level deadlocks;
- GC- or STW- pauses;
- threadpool starvation events.

Best candidates (as monitoring tool) are WebConsole and VisorConsole



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

[jira] [Updated] (IGNITE-6960) ContinuousQuery failed if set deploymentMode to Private

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov updated IGNITE-6960:
--
Affects Version/s: 2.3

> ContinuousQuery failed if set deploymentMode to Private
> ---
>
> Key: IGNITE-6960
> URL: https://issues.apache.org/jira/browse/IGNITE-6960
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Priority: Critical
> Fix For: 2.4
>
>
> user list: 
> http://apache-ignite-users.70518.x6.nabble.com/Scan-query-failed-if-set-deploymentMode-to-Private-tt18244.html



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

[jira] [Updated] (IGNITE-6960) ContinuousQuery failed if set deploymentMode to Private

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov updated IGNITE-6960:
--
Fix Version/s: 2.4

> ContinuousQuery failed if set deploymentMode to Private
> ---
>
> Key: IGNITE-6960
> URL: https://issues.apache.org/jira/browse/IGNITE-6960
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Priority: Critical
> Fix For: 2.4
>
>
> user list: 
> http://apache-ignite-users.70518.x6.nabble.com/Scan-query-failed-if-set-deploymentMode-to-Private-tt18244.html



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

[jira] [Created] (IGNITE-6960) ContinuousQuery failed if set deploymentMode to Private

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-6960:
-

 Summary: ContinuousQuery failed if set deploymentMode to Private
 Key: IGNITE-6960
 URL: https://issues.apache.org/jira/browse/IGNITE-6960
 Project: Ignite
  Issue Type: Bug
  Components: cache, general
Reporter: Mikhail Cherkasov
Priority: Critical


user list: 
http://apache-ignite-users.70518.x6.nabble.com/Scan-query-failed-if-set-deploymentMode-to-Private-tt18244.html



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

[jira] [Commented] (IGNITE-6406) SQL: CREATE INDEX should fill index from multiple threads

[Roman Kondakov (JIRA)]

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

Roman Kondakov commented on IGNITE-6406:


[~vozerov] please review. Tests are OK.

> SQL: CREATE INDEX should fill index from multiple threads
> -
>
> Key: IGNITE-6406
> URL: https://issues.apache.org/jira/browse/IGNITE-6406
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently when {{CREATE INDEX}} command is executed, we fill new index from a 
> single thread. Low CPU, long create time. We can trade off CPU vs time by 
> adding more threads. 
> Probably number of threads should be specified in {{CREATE INDEX}} command as 
> a hint.



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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6955:
--

[~alexey.tank2]
Looks good to me. 
Please check sources can be compiled after .m2 repo cleanup. 
Also please check Examples task at TeamCity.

> 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-6959) Split a ttl index tree by partition

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin reassigned IGNITE-6959:
--

Assignee: Alexey Goncharuk  (was: Sergey Puchnin)

> Split a ttl index tree by partition  
> -
>
> Key: IGNITE-6959
> URL: https://issues.apache.org/jira/browse/IGNITE-6959
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Alexey Goncharuk
>Priority: Minor
>
> Now a tree to trace an entries' TTL presented only one per a node. To improve 
> a performance need to split the tree per partition. 



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

Pavel Tupitsyn commented on IGNITE-2662:


IGNITE_HOME and JAVA_HOME detection fixed.
.NET Core plugin has been installed on TeamCity, first tests pass on Linux.

What is left:
* Add more tests for all components (Cache, Compute, Serialization, LINQ, 
persistence, logging)


> .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] [Updated] (IGNITE-6959) Split a ttl index tree by partition

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6959:
---
Description: 
Now a tree to trace an entries' TTL presented only one per a node. To improve a 
performance need to split the tree per partition. 


  was:
Now a tree to trace an entries' TTL presented only one per a node. To improve a 
performace need to 



> Split a ttl index tree by partition  
> -
>
> Key: IGNITE-6959
> URL: https://issues.apache.org/jira/browse/IGNITE-6959
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Sergey Puchnin
>Priority: Minor
>
> Now a tree to trace an entries' TTL presented only one per a node. To improve 
> a performance need to split the tree per partition. 



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

[jira] [Updated] (IGNITE-6959) Split a ttl index tree by partition

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6959:
---
Description: 
Now a tree to trace an entries' TTL presented only one per a node. To improve a 
performace need to 


  was:
h2. Use Case
* User starts up cluster of N nodes and fills it with some data.
* User splits the cluster into two halves and modifies data in each half 
independently.
* User tries to join two halves back into one - irresolvable conflicts in data 
for the same key may happen.

h2. BaselineTopology Versioning
Each BLT contains enough information to check its compatibility with other BLT. 
If BLT of joining node is not compatible with BLT grid is working on at the 
moment, node is not allowed to join the grid and must fail with proper 
exception.



> Split a ttl index tree by partition  
> -
>
> Key: IGNITE-6959
> URL: https://issues.apache.org/jira/browse/IGNITE-6959
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Sergey Puchnin
>Priority: Minor
>
> Now a tree to trace an entries' TTL presented only one per a node. To improve 
> a performace need to 



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

[jira] [Updated] (IGNITE-6959) Split a ttl index tree by partition

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6959:
---
Labels:   (was: IEP-4)

> Split a ttl index tree by partition  
> -
>
> Key: IGNITE-6959
> URL: https://issues.apache.org/jira/browse/IGNITE-6959
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Sergey Puchnin
>Priority: Minor
>
> h2. Use Case
> * User starts up cluster of N nodes and fills it with some data.
> * User splits the cluster into two halves and modifies data in each half 
> independently.
> * User tries to join two halves back into one - irresolvable conflicts in 
> data for the same key may happen.
> h2. BaselineTopology Versioning
> Each BLT contains enough information to check its compatibility with other 
> BLT. If BLT of joining node is not compatible with BLT grid is working on at 
> the moment, node is not allowed to join the grid and must fail with proper 
> exception.



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

[jira] [Created] (IGNITE-6959) Split a ttl index tree by partition

[Sergey Puchnin (JIRA)]

Sergey Puchnin created IGNITE-6959:
--

 Summary: Split a ttl index tree by partition  
 Key: IGNITE-6959
 URL: https://issues.apache.org/jira/browse/IGNITE-6959
 Project: Ignite
  Issue Type: Task
  Components: persistence
Reporter: Sergey Puchnin
Assignee: Sergey Chugunov


h2. Use Case
* User starts up cluster of N nodes and fills it with some data.
* User splits the cluster into two halves and modifies data in each half 
independently.
* User tries to join two halves back into one - irresolvable conflicts in data 
for the same key may happen.

h2. BaselineTopology Versioning
Each BLT contains enough information to check its compatibility with other BLT. 
If BLT of joining node is not compatible with BLT grid is working on at the 
moment, node is not allowed to join the grid and must fail with proper 
exception.




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

[jira] [Updated] (IGNITE-6959) Split a ttl index tree by partition

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6959:
---
Issue Type: Improvement  (was: Task)

> Split a ttl index tree by partition  
> -
>
> Key: IGNITE-6959
> URL: https://issues.apache.org/jira/browse/IGNITE-6959
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Sergey Chugunov
>  Labels: IEP-4
>
> h2. Use Case
> * User starts up cluster of N nodes and fills it with some data.
> * User splits the cluster into two halves and modifies data in each half 
> independently.
> * User tries to join two halves back into one - irresolvable conflicts in 
> data for the same key may happen.
> h2. BaselineTopology Versioning
> Each BLT contains enough information to check its compatibility with other 
> BLT. If BLT of joining node is not compatible with BLT grid is working on at 
> the moment, node is not allowed to join the grid and must fail with proper 
> exception.



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

[jira] [Updated] (IGNITE-6959) Split a ttl index tree by partition

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin updated IGNITE-6959:
---
Priority: Minor  (was: Major)

> Split a ttl index tree by partition  
> -
>
> Key: IGNITE-6959
> URL: https://issues.apache.org/jira/browse/IGNITE-6959
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Sergey Chugunov
>Priority: Minor
>  Labels: IEP-4
>
> h2. Use Case
> * User starts up cluster of N nodes and fills it with some data.
> * User splits the cluster into two halves and modifies data in each half 
> independently.
> * User tries to join two halves back into one - irresolvable conflicts in 
> data for the same key may happen.
> h2. BaselineTopology Versioning
> Each BLT contains enough information to check its compatibility with other 
> BLT. If BLT of joining node is not compatible with BLT grid is working on at 
> the moment, node is not allowed to join the grid and must fail with proper 
> exception.



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

[jira] [Assigned] (IGNITE-6959) Split a ttl index tree by partition

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin reassigned IGNITE-6959:
--

Assignee: Sergey Puchnin  (was: Sergey Chugunov)

> Split a ttl index tree by partition  
> -
>
> Key: IGNITE-6959
> URL: https://issues.apache.org/jira/browse/IGNITE-6959
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Sergey Puchnin
>Assignee: Sergey Puchnin
>Priority: Minor
>  Labels: IEP-4
>
> h2. Use Case
> * User starts up cluster of N nodes and fills it with some data.
> * User splits the cluster into two halves and modifies data in each half 
> independently.
> * User tries to join two halves back into one - irresolvable conflicts in 
> data for the same key may happen.
> h2. BaselineTopology Versioning
> Each BLT contains enough information to check its compatibility with other 
> BLT. If BLT of joining node is not compatible with BLT grid is working on at 
> the moment, node is not allowed to join the grid and must fail with proper 
> exception.



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

[jira] [Assigned] (IGNITE-6310) BaselineTopology versioning

[Sergey Puchnin (JIRA)]

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

Sergey Puchnin reassigned IGNITE-6310:
--

Assignee: (was: Sergey Chugunov)

> BaselineTopology versioning
> ---
>
> Key: IGNITE-6310
> URL: https://issues.apache.org/jira/browse/IGNITE-6310
> Project: Ignite
>  Issue Type: Task
>  Components: persistence
>Reporter: Sergey Chugunov
>  Labels: IEP-4
>
> h2. Use Case
> * User starts up cluster of N nodes and fills it with some data.
> * User splits the cluster into two halves and modifies data in each half 
> independently.
> * User tries to join two halves back into one - irresolvable conflicts in 
> data for the same key may happen.
> h2. BaselineTopology Versioning
> Each BLT contains enough information to check its compatibility with other 
> BLT. If BLT of joining node is not compatible with BLT grid is working on at 
> the moment, node is not allowed to join the grid and must fail with proper 
> exception.



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

[jira] [Commented] (IGNITE-6876) ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6876:


GitHub user isapego opened a pull request:

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

IGNITE-6876: ODBC: Added support for SQL_ATTR_CONNECTION_TIMEOUT



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

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

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

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


commit a503033eeb13a24f335a7393fce801b26025d26f
Author: Igor Sapego 
Date:   2017-11-17T16:32:28Z

IGNITE-6876: Implemented for Windows

commit 33517f2e4b4186de9239ff153c691895ddbe965e
Author: Igor Sapego 
Date:   2017-11-17T17:33:33Z

IGNITE-6876: Fixed

commit a674f9bc4acb9de956b39bc08d67bd2d440b
Author: Igor Sapego 
Date:   2017-11-20T09:18:39Z

IGNITE-6876: Added timeout for queries

commit 1ff14fbec7b6757ff1ce3229dace6059ed563645
Author: Igor Sapego 
Date:   2017-11-20T09:44:32Z

IGNITE-6876: Added test

commit 28baac25e7ade92f5b0074cb74e7ce2671e0d233
Author: Igor Sapego 
Date:   2017-11-20T10:25:04Z

IGNITE-6876: Added tests

commit 8d70c4da9e711a4477e6d3f2679deed4e13325da
Author: Igor Sapego 
Date:   2017-11-20T11:34:39Z

IGNITE-6876: Linux part implemented

commit d56a0986da23e33162fc9d88d6ed4c37e0c7937d
Author: Igor Sapego 
Date:   2017-11-20T11:50:41Z

IGNITE-6876: Linux fixes




> ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT
> -
>
> Key: IGNITE-6876
> URL: https://issues.apache.org/jira/browse/IGNITE-6876
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> Remote ODBC client should be able to request a timeout for socket 
> send/receive operations. It should be done with 
> {{SQL_ATTR_CONNECTION_TIMEOUT}} attribute.
> If an application with ODBC driver experiences a timeout for some query, it 
> can continue to work after closing the connection and establishing a new one.



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

[jira] [Commented] (IGNITE-6895) TX deadlock monitoring

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6895:
--

Alternative case:
Deadlock detection and timeouts are to be enforced for all transactions via 
grid-wide parameter.

> TX deadlock monitoring
> --
>
> Key: IGNITE-6895
> URL: https://issues.apache.org/jira/browse/IGNITE-6895
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>  Labels: iep-7
>
> Deadlocks with Cache Transactions
> Description
> Deadlocks of this type are possible if user locks 2 or more keys within 2 or 
> more transactions in different orders (this does not apply to OPTIMISTIC 
> SERIALIZABLE transactions as they are capable to detect deadlock and choose 
> winning tx). Currently, Ignite can detect deadlocked transactions but this 
> procedure is started only for transactions that have timeout set explicitly 
> or default timeout in configuration set to value greater than 0.
> Detection and Solution
> Each NEAR node should periodically (need new config property?) scan the list 
> of local transactions and initiate the same procedure as we have now for 
> timed out transactions. If deadlock found it should be reported to logs. Log 
> record should contain: near nodes, transaction IDs, cache names, keys 
> (limited to several tens of) involved in deadlock. User should have ability 
> to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually 
> rollback selected transaction through web console or Visor.
> Report
> If deadlock found it should be reported to logs. Log record should contain: 
> near nodes, transaction IDs, cache names, keys (limited to several tens of) 
> involved in deadlock.
> Also there should be a screen in Web Console that will list all ongoing 
> transactions in the cluster including the following info:
> - Near node
> - Start time
> - DHT nodes
> - Pending Locks (by request)
> Web Console should provide ability to rollback any transaction via UI.



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

[jira] [Commented] (IGNITE-6944) Fail to execute task with immutable list string

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6944:
-

This fix will break IGNITE-6485. I'll take a look and share my findings.

> Fail to execute task with immutable list string
> ---
>
> Key: IGNITE-6944
> URL: https://issues.apache.org/jira/browse/IGNITE-6944
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.3
>Reporter: Edmond Tsang
> Attachments: BinaryMarshellerWithGuavaSelfTest.java, 
> TestClientWithGuava.java
>
>
> Exception occurs when executing task with immutable list of string due to not 
> able to find method readResolve/writeReplace for binary object.
> It appears this is caused by a side effect of Jira 
> https://issues.apache.org/jira/browse/IGNITE-6485 



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

Anton Vinogradov commented on IGNITE-6171:
--

Since no one  rejected idea propose to start with first part of devlis's 
duscussion

{noformat}
I propose to add a special thread that will record current time every N 
milliseconds and check the difference with the latest recorded value. 
The maximum and total pause values for a certain period can be published in 
the special metrics available through JMX. 
{noformat}

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

Anton Vinogradov edited comment on IGNITE-6171 at 11/20/17 11:53 AM:
-

[~cyberdemon],

Since no one rejected idea propose to start with first part of devlis's 
duscussion

{noformat}
I propose to add a special thread that will record current time every N 
milliseconds and check the difference with the latest recorded value. 
The maximum and total pause values for a certain period can be published in 
the special metrics available through JMX. 
{noformat}


was (Author: avinogradov):
Since no one  rejected idea propose to start with first part of devlis's 
duscussion

{noformat}
I propose to add a special thread that will record current time every N 
milliseconds and check the difference with the latest recorded value. 
The maximum and total pause values for a certain period can be published in 
the special metrics available through JMX. 
{noformat}

> 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-6894) Hanged Tx monitoring

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6894:
-
Description: 
Hanging Transactions not Related to Deadlock

Description
This situation can occur if user explicitly markups the transaction (esp 
Pessimistic Repeatable Read) and, for example, calls remote service (which may 
be unresponsive) after acquiring some locks. All other transactions depending 
on the same keys will hang.

Detection and Solution
This most likely cannot be resolved automatically other than rollback TX by 
timeout and release all the locks acquired so far. Also such TXs can be rolled 
back from Web Console as described above.
If transaction has been rolled back on timeout or via UI then any further 
action in the transaction, e.g. lock acquisition or commit attempt should throw 
exception.

Report
Web Console should provide ability to rollback any transaction via UI.
Long running transaction should be reported to logs. Log record should contain: 
near nodes, transaction IDs, cache names, keys (limited to several tens of), 
etc ( ?).

Also there should be a screen in Web Console that will list all ongoing 
transactions in the cluster including the info as above.

> Hanged Tx monitoring
> 
>
> Key: IGNITE-6894
> URL: https://issues.apache.org/jira/browse/IGNITE-6894
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>  Labels: iep-7
>
> Hanging Transactions not Related to Deadlock
> Description
> This situation can occur if user explicitly markups the transaction (esp 
> Pessimistic Repeatable Read) and, for example, calls remote service (which 
> may be unresponsive) after acquiring some locks. All other transactions 
> depending on the same keys will hang.
> Detection and Solution
> This most likely cannot be resolved automatically other than rollback TX by 
> timeout and release all the locks acquired so far. Also such TXs can be 
> rolled back from Web Console as described above.
> If transaction has been rolled back on timeout or via UI then any further 
> action in the transaction, e.g. lock acquisition or commit attempt should 
> throw exception.
> Report
> Web Console should provide ability to rollback any transaction via UI.
> Long running transaction should be reported to logs. Log record should 
> contain: near nodes, transaction IDs, cache names, keys (limited to several 
> tens of), etc ( ?).
> Also there should be a screen in Web Console that will list all ongoing 
> transactions in the cluster including the info as above.



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