[jira] [Closed] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-4821.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

Merged to master.

> Web Console: Add EnforceJoinOrder option on Queries screen
> --
>
> Key: IGNITE-4821
> URL: https://issues.apache.org/jira/browse/IGNITE-4821
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrey Novikov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
>
> Add support for on Query tab.
> {code:java}
> SqlFieldsQuery.setEnforceJoinOrder(true);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-4821:
--

Assignee: Andrey Novikov  (was: Pavel Konstantinov)

> Web Console: Add EnforceJoinOrder option on Queries screen
> --
>
> Key: IGNITE-4821
> URL: https://issues.apache.org/jira/browse/IGNITE-4821
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Minor
> Fix For: 2.0
>
>
> Add support for on Query tab.
> {code:java}
> SqlFieldsQuery.setEnforceJoinOrder(true);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4821:


Successfully tested. Please merge.

> Web Console: Add EnforceJoinOrder option on Queries screen
> --
>
> Key: IGNITE-4821
> URL: https://issues.apache.org/jira/browse/IGNITE-4821
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.0
>
>
> Add support for on Query tab.
> {code:java}
> SqlFieldsQuery.setEnforceJoinOrder(true);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-4821:


Reviewed. Looks good for me. [~pkonstantinov], please test.

> Web Console: Add EnforceJoinOrder option on Queries screen
> --
>
> Key: IGNITE-4821
> URL: https://issues.apache.org/jira/browse/IGNITE-4821
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Minor
> Fix For: 2.0
>
>
> Add support for on Query tab.
> {code:java}
> SqlFieldsQuery.setEnforceJoinOrder(true);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-4821:
---

Implemented enforce join option on query execution in Web console.

> Web Console: Add EnforceJoinOrder option on Queries screen
> --
>
> Key: IGNITE-4821
> URL: https://issues.apache.org/jira/browse/IGNITE-4821
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrey Novikov
>Assignee: Vasiliy Sisko
>Priority: Minor
> Fix For: 2.0
>
>
> Add support for on Query tab.
> {code:java}
> SqlFieldsQuery.setEnforceJoinOrder(true);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-4821:
-

Assignee: Andrey Novikov  (was: Vasiliy Sisko)

> Web Console: Add EnforceJoinOrder option on Queries screen
> --
>
> Key: IGNITE-4821
> URL: https://issues.apache.org/jira/browse/IGNITE-4821
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Minor
> Fix For: 2.0
>
>
> Add support for on Query tab.
> {code:java}
> SqlFieldsQuery.setEnforceJoinOrder(true);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-4821:
-

Assignee: Vasiliy Sisko

> Web Console: Add EnforceJoinOrder option on Queries screen
> --
>
> Key: IGNITE-4821
> URL: https://issues.apache.org/jira/browse/IGNITE-4821
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrey Novikov
>Assignee: Vasiliy Sisko
>Priority: Minor
> Fix For: 2.0
>
>
> Add support for on Query tab.
> {code:java}
> SqlFieldsQuery.setEnforceJoinOrder(true);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-4821:
---
Description: 
Add support for on Query tab.
{code:java}
SqlFieldsQuery.setEnforceJoinOrder(true);
{code}

> Web Console: Add EnforceJoinOrder option on Queries screen
> --
>
> Key: IGNITE-4821
> URL: https://issues.apache.org/jira/browse/IGNITE-4821
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrey Novikov
>Priority: Minor
> Fix For: 2.0
>
>
> Add support for on Query tab.
> {code:java}
> SqlFieldsQuery.setEnforceJoinOrder(true);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4821) Web Console: Add EnforceJoinOrder option on Queries screen

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-4821:
--

 Summary: Web Console: Add EnforceJoinOrder option on Queries screen
 Key: IGNITE-4821
 URL: https://issues.apache.org/jira/browse/IGNITE-4821
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Andrey Novikov
Priority: Minor
 Fix For: 2.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4816) Issue with refresh rate on queries

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-4816:
--

Assignee: Pavel Konstantinov  (was: Andrey Novikov)

> Issue with refresh rate on queries
> --
>
> Key: IGNITE-4816
> URL: https://issues.apache.org/jira/browse/IGNITE-4816
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> Next query execution start before previous one is finished



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (IGNITE-933) GridFailFastNodeFailureDetectionSelfTest.testFailFast fails periodically

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-933.
--

> GridFailFastNodeFailureDetectionSelfTest.testFailFast fails periodically
> 
>
> Key: IGNITE-933
> URL: https://issues.apache.org/jira/browse/IGNITE-933
> Project: Ignite
>  Issue Type: Bug
>  Components: general, newbie
>Affects Versions: sprint-5
>Reporter: Denis Magda
>Assignee: Vadim Opolski
>  Labels: newbie
>
> The timeout for latch (500 millis) seems to be not enough for some machines. 
> Investigate and fix appropriately. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-933) GridFailFastNodeFailureDetectionSelfTest.testFailFast fails periodically

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-933:


Vadim, thanks. I've insured a bit and increased the timeout to 1500 millis. 
Merged the changes.

> GridFailFastNodeFailureDetectionSelfTest.testFailFast fails periodically
> 
>
> Key: IGNITE-933
> URL: https://issues.apache.org/jira/browse/IGNITE-933
> Project: Ignite
>  Issue Type: Bug
>  Components: general, newbie
>Affects Versions: sprint-5
>Reporter: Denis Magda
>Assignee: Vadim Opolski
>  Labels: newbie
>
> The timeout for latch (500 millis) seems to be not enough for some machines. 
> Investigate and fix appropriately. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4812) Disable EventStorageSpi by default

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4812:
-

Hey Alper,

Sure, will take a look during next few days.

> Disable EventStorageSpi by default
> --
>
> Key: IGNITE-4812
> URL: https://issues.apache.org/jira/browse/IGNITE-4812
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Alper Tekinalp
> Fix For: 2.0
>
>
> Current default implementation of {{EventStorageSpi}} is 
> {{MemoryEventStorageSpi}}. It consumes a lot of memory, while is used only 
> for events querying (i.e. not listening), which is a fairly rare use case.
> Need to:
> * Introduce {{NoOpEventStorageSpi}}.
> * Make {{NoOpEventStorageSpi}} the default one.
> * Throw an exception when {{IgniteEvents#localQuery}} or {{#remoteQuery}} 
> method is called with default setting. Exception message should explain how 
> to fix it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4812) Disable EventStorageSpi by default

[Alper Tekinalp (JIRA)]

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

Alper Tekinalp commented on IGNITE-4812:


Hi [~vkulichenko].

Can you review the pull request please: 
https://github.com/apache/ignite/pull/1623.

> Disable EventStorageSpi by default
> --
>
> Key: IGNITE-4812
> URL: https://issues.apache.org/jira/browse/IGNITE-4812
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Alper Tekinalp
> Fix For: 2.0
>
>
> Current default implementation of {{EventStorageSpi}} is 
> {{MemoryEventStorageSpi}}. It consumes a lot of memory, while is used only 
> for events querying (i.e. not listening), which is a fairly rare use case.
> Need to:
> * Introduce {{NoOpEventStorageSpi}}.
> * Make {{NoOpEventStorageSpi}} the default one.
> * Throw an exception when {{IgniteEvents#localQuery}} or {{#remoteQuery}} 
> method is called with default setting. Exception message should explain how 
> to fix it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4812) Disable EventStorageSpi by default

[Alper Tekinalp (JIRA)]

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

Alper Tekinalp reassigned IGNITE-4812:
--

Assignee: Alper Tekinalp

> Disable EventStorageSpi by default
> --
>
> Key: IGNITE-4812
> URL: https://issues.apache.org/jira/browse/IGNITE-4812
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Alper Tekinalp
> Fix For: 2.0
>
>
> Current default implementation of {{EventStorageSpi}} is 
> {{MemoryEventStorageSpi}}. It consumes a lot of memory, while is used only 
> for events querying (i.e. not listening), which is a fairly rare use case.
> Need to:
> * Introduce {{NoOpEventStorageSpi}}.
> * Make {{NoOpEventStorageSpi}} the default one.
> * Throw an exception when {{IgniteEvents#localQuery}} or {{#remoteQuery}} 
> method is called with default setting. Exception message should explain how 
> to fix it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-3575) CPP: Support continuous queries remote filters.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3575:


GitHub user isapego opened a pull request:

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

IGNITE-3575: CPP: Implemented remote filters for continuous queries



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

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

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

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


commit 3c7e6a1d09dce8330de1fb27205c7e19c4588eb8
Author: Igor Sapego 
Date:   2017-03-07T12:51:21Z

IGNITE-3575: Added CacheEntryEventFilter

commit decf08ef4789e76a22cbf67b474141d0fbd8066d
Author: Igor Sapego 
Date:   2017-03-10T17:38:12Z

IGNITE-3575: Added CacheEntryEventFilterHolder

commit 33263d9f0f8b61612630fc102b99137236b79836
Author: Igor Sapego 
Date:   2017-03-13T14:21:27Z

IGNITE-3575: Added test

commit 8ad02351697266da287adfe678a4de15aaeb5049
Author: Igor Sapego 
Date:   2017-03-13T17:01:55Z

IGNITE-3575: Refactored IgniteBindingImpl

commit a00dff47cffd3d35bf198e2d775178b05d6b0837
Author: Igor Sapego 
Date:   2017-03-14T11:47:01Z

IGNITE-3575: Implemented filter creation.

commit 04c57b373706d8afe59a07413509207dd8d8c228
Author: Igor Sapego 
Date:   2017-03-14T13:26:22Z

IGNITE-3575: Fully implemented. Not tested. Refactoring required.

commit 3da327e437fe0bf893ed7da3ba3f9522708898f8
Author: Igor Sapego 
Date:   2017-03-14T15:12:34Z

IGNITE-3575: Implemented for local case

commit b67b6d89af30c5d6702a9e1e5e7d4e979ab23b95
Author: Igor Sapego 
Date:   2017-03-14T15:53:20Z

IGNITE-3575: implemented for remote nodes.

commit 62b45757f4b0ca9bebb71b5b4add1a6f1c3a5e86
Author: Igor Sapego 
Date:   2017-03-14T16:41:32Z

IGNITE-3575: Refactoring

commit 10b9bdf4ee2198912341336b8ddbddb299829e6b
Author: Igor Sapego 
Date:   2017-03-14T17:03:25Z

IGNITE-3575: Redactoring.

commit 931b3ef38a48708383537101264bb05a32117efe
Author: Igor Sapego 
Date:   2017-03-14T17:12:10Z

Merge remote-tracking branch 'upstream/ignite-2.0' into ignite-3575




> CPP: Support continuous queries remote filters.
> ---
>
> Key: IGNITE-3575
> URL: https://issues.apache.org/jira/browse/IGNITE-3575
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: (was: 400.png)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: balanced.003.png, balanced.004.png, balanced.008.png, 
> balanced.016.png, balanced.064.png, balanced.100.png, balanced.128.png, 
> balanced.200.png, balanced.256.png, balanced.400.png, balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: (was: 064.png)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: balanced.003.png, balanced.004.png, balanced.008.png, 
> balanced.016.png, balanced.064.png, balanced.100.png, balanced.128.png, 
> balanced.200.png, balanced.256.png, balanced.400.png, balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: (was: 300.png)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: balanced.003.png, balanced.004.png, balanced.008.png, 
> balanced.016.png, balanced.064.png, balanced.100.png, balanced.128.png, 
> balanced.200.png, balanced.256.png, balanced.400.png, balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: (was: 500.png)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: balanced.003.png, balanced.004.png, balanced.008.png, 
> balanced.016.png, balanced.064.png, balanced.100.png, balanced.128.png, 
> balanced.200.png, balanced.256.png, balanced.400.png, balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: (was: 100.png)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: balanced.003.png, balanced.004.png, balanced.008.png, 
> balanced.016.png, balanced.064.png, balanced.100.png, balanced.128.png, 
> balanced.200.png, balanced.256.png, balanced.400.png, balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: (was: 200.png)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: balanced.003.png, balanced.004.png, balanced.008.png, 
> balanced.016.png, balanced.064.png, balanced.100.png, balanced.128.png, 
> balanced.200.png, balanced.256.png, balanced.400.png, balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: (was: 600.png)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: balanced.003.png, balanced.004.png, balanced.008.png, 
> balanced.016.png, balanced.064.png, balanced.100.png, balanced.128.png, 
> balanced.200.png, balanced.256.png, balanced.400.png, balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: (was: 003.png)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: balanced.003.png, balanced.004.png, balanced.008.png, 
> balanced.016.png, balanced.064.png, balanced.100.png, balanced.128.png, 
> balanced.200.png, balanced.256.png, balanced.400.png, balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-3018:
-
Attachment: balanced.600.png
balanced.400.png
balanced.256.png
balanced.200.png
balanced.128.png
balanced.100.png
balanced.064.png
balanced.016.png
balanced.008.png
balanced.004.png
balanced.003.png

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: 003.png, 064.png, 100.png, 128.png, 200.png, 300.png, 
> 400.png, 500.png, 600.png, balanced.003.png, balanced.004.png, 
> balanced.008.png, balanced.016.png, balanced.064.png, balanced.100.png, 
> balanced.128.png, balanced.200.png, balanced.256.png, balanced.400.png, 
> balanced.600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4699) Introduce custom configurable executors.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4699:
--

[~sharpler],
1. Please clarify the question. I think the answer is "only to separate the 
jobs into groups" (see *p.3* below);
2. Now in the Ignite a thread pool is configured only with the pool size, 
without names, keep alive params etc. It is simple and enough;
3. It must solve the deadlock in case the one compute job (*A*) produces 
another compute jobs (*B*). If all the jobs use one thread pool and thread 
starvation is happened the *A* job waits for compute results and hold the 
thread and there are no free threads in the pool to execute *B* jobs.

> Introduce custom configurable executors.
> 
>
> Key: IGNITE-4699
> URL: https://issues.apache.org/jira/browse/IGNITE-4699
> Project: Ignite
>  Issue Type: Task
>  Components: compute
>Reporter: Vladimir Ozerov
>Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> We need to provide a way to configure custom thread pools for user compute 
> tasks. 
> Proposed API:
> 1) Config
> {code}
> class ExecutorConfiguration {
> String name;
> int size;
> }
> {code}
> 2) Choosing executor for compute task:
> {code}
> IgniteCompute compute = Ignite.compute().withExecutor("my_exec");
> {code}
> 3) Accessing raw executor (could be required for proper execution of future 
> listeners):
> {code}
> ThreadPoolExecutor exec = ignite.compute().localExecutor("my_exec");
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-3481) Implement lazy query execution in H2.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-3481:
-
Fix Version/s: 2.0

> Implement lazy query execution in H2.
> -
>
> Key: IGNITE-3481
> URL: https://issues.apache.org/jira/browse/IGNITE-3481
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Reporter: Sergi Vladykin
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4795) Inherit TransactionException and update Javadoc

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-4795:


[~ein], I added note about put/get (item 4) in javadoc of Transaction class. 
But I'm not sure about third item. I don't know what to write about methods 
behaviour. Can you suggest anything?

You also can check my changes here 
https://github.com/SomeFire/ignite/pull/3/files

> Inherit TransactionException and update Javadoc
> ---
>
> Key: IGNITE-4795
> URL: https://issues.apache.org/jira/browse/IGNITE-4795
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, SQL, website
>Affects Versions: 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Ryabov Dmitrii
>  Labels: documentation
> Fix For: 2.0
>
>
> Understanding transactional behaviour is not clear in Javadoc at this point 
> of time. Even after reading website some doubt remain.
> Proposal.
> 1. Create {{TransactionException}} as the marker of transactional methods and 
> inherit from it all the existed transactional exceptions like 
> {{TransactionTimeoutException}}, {{TransactionRollbackException}}, 
> {{TransactionHeuristicException}}, {{TransactionOptimisticException}}, etc.
> 2. Update all the transactional methods ({{get}}, {{put}}, {{invoke}}, etc) 
> as throwing the base {{TransactionException}}. Comment all the 
> {{IgniteCache}} methods whether they are transactional or not, add {{@see 
> TransactionException}} annotation.
> 3. Make extensive documentation in the header of {{TransactionException}} to 
> get understanding of transactional and non-transactional methods behaviour.
> 4. Update website and Javadoc to clarify the fact that {{put}} value is 
> cached within the transaction and affects successive {{get}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-2790) LGPL CacheHibernateStoreExample fails if it runs w/o IDEA

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov resolved IGNITE-2790.
---
Resolution: Not A Bug

> LGPL CacheHibernateStoreExample fails if it runs w/o IDEA
> -
>
> Key: IGNITE-2790
> URL: https://issues.apache.org/jira/browse/IGNITE-2790
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>
> 1. Build and package examples via maven:
> {noformat}
> c:\Work>cd examples
> c:\Work\examples>mvn clean package -Plgpl
> {noformat}
> 2. Copy example jar in {{libs}} directory
> 3. Run CachePutGetExample to make sure that it works
> {noformat}
> c:\Work>c:\java\jdk1.7.0_80\bin\java -cp c:\Work\libs\
> *;C:\Work\libs\ignite-indexing\*;C:\Work\libs\ignite-s
> pring\* org.apache.ignite.examples.datagrid.CachePutGetExample
> ...
> [11:04:06] Topology snapshot [ver=1, servers=1, clients=0, C
> >>> Cache put-get example started.
> >>> Stored values in cache.
> Got [key=0, val=0]
> Got [key=1, val=1]
> Got [key=2, val=2]
> Got [key=3, val=3]
> Got [key=4, val=4]
> Got [key=5, val=5]
> Got [key=6, val=6]
> Got [key=7, val=7]
> Got [key=8, val=8]
> Got [key=9, val=9]
> Got [key=10, val=10]
> Got [key=11, val=11]
> Got [key=12, val=12]
> Got [key=13, val=13]
> Got [key=14, val=14]
> Got [key=15, val=15]
> Got [key=16, val=16]
> Got [key=17, val=17]
> Got [key=18, val=18]
> Got [key=19, val=19]
> >>> Starting putAll-getAll example.
> >>> Bulk-stored values in cache.
> Got entry [key=0, val=bulk-0]
> Got entry [key=1, val=bulk-1]
> Got entry [key=2, val=bulk-2]
> Got entry [key=3, val=bulk-3]
> Got entry [key=4, val=bulk-4]
> Got entry [key=5, val=bulk-5]
> Got entry [key=6, val=bulk-6]
> Got entry [key=7, val=bulk-7]
> Got entry [key=8, val=bulk-8]
> Got entry [key=9, val=bulk-9]
> Got entry [key=10, val=bulk-10]
> Got entry [key=11, val=bulk-11]
> Got entry [key=12, val=bulk-12]
> Got entry [key=13, val=bulk-13]
> Got entry [key=14, val=bulk-14]
> Got entry [key=15, val=bulk-15]
> Got entry [key=17, val=bulk-17]
> Got entry [key=16, val=bulk-16]
> Got entry [key=19, val=bulk-19]
> Got entry [key=18, val=bulk-18]
> [11:04:06] Ignite node stopped OK [uptime=00:00:00:254]
> {noformat}
> 4. Copy directory {{libs/optional/ignite-hibernate}} in {{libs/}}
> 5. Run CacheHibernateStoreExample. It fails with ClassNotFoundException:
> {noformat}
> c:\Work>c:\java\jdk1.7.0_80\bin\java -cp c:\Work\libs\
> *;C:\Work\libs\ignite-indexing\*;C:\Work\libs\ignite-s
> pring\*;C:\Work\libs\ignite-hibernate\* 
> org.apache.ignite.examples.datagrid.store.hiber
> nate.CacheHibernateStoreExample
> [11:06:38]__  
> [11:06:38]   /  _/ ___/ |/ /  _/_  __/ __/
> [11:06:38]  _/ // (7 7// /  / / / _/
> [11:06:38] /___/\___/_/|_/___/ /_/ /___/
> [11:06:38]
> ...
> [11:06:51] Ignite node started OK (id=16d64392)
> [11:06:51] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=3.5GB]
> >>> Cache store example started.
> [11:06:51,926][SEVERE][exchange-worker-#49%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitio
> ns (preloading will be stopped): GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], n
> odeId=16d64392, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NoClassDefFoundError: 
> org/hibernate/annotations/common/reflection/ReflectionManager
> at 
> org.apache.ignite.cache.store.hibernate.CacheHibernateStoreSessionListener.start(CacheHibernateStoreSessionLi
> stener.java:161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.startStoreSessionListeners(GridCacheUtils.java:171
> 2)
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.start0(GridCacheStoreManagerAd
> apter.java:213)
> at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:64)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1042)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1639
> )
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCachesStart(GridCacheProcessor.java:155
> 4)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.startCa
> ches(GridDhtPartitionsExchangeFuture.java:960)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(Gr
> idDhtPartitionsExchangeFuture.java:523)
> at 
> 

[jira] [Closed] (IGNITE-2790) LGPL CacheHibernateStoreExample fails if it runs w/o IDEA

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov closed IGNITE-2790.
-
Assignee: Sergey Kozlov

> LGPL CacheHibernateStoreExample fails if it runs w/o IDEA
> -
>
> Key: IGNITE-2790
> URL: https://issues.apache.org/jira/browse/IGNITE-2790
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>
> 1. Build and package examples via maven:
> {noformat}
> c:\Work>cd examples
> c:\Work\examples>mvn clean package -Plgpl
> {noformat}
> 2. Copy example jar in {{libs}} directory
> 3. Run CachePutGetExample to make sure that it works
> {noformat}
> c:\Work>c:\java\jdk1.7.0_80\bin\java -cp c:\Work\libs\
> *;C:\Work\libs\ignite-indexing\*;C:\Work\libs\ignite-s
> pring\* org.apache.ignite.examples.datagrid.CachePutGetExample
> ...
> [11:04:06] Topology snapshot [ver=1, servers=1, clients=0, C
> >>> Cache put-get example started.
> >>> Stored values in cache.
> Got [key=0, val=0]
> Got [key=1, val=1]
> Got [key=2, val=2]
> Got [key=3, val=3]
> Got [key=4, val=4]
> Got [key=5, val=5]
> Got [key=6, val=6]
> Got [key=7, val=7]
> Got [key=8, val=8]
> Got [key=9, val=9]
> Got [key=10, val=10]
> Got [key=11, val=11]
> Got [key=12, val=12]
> Got [key=13, val=13]
> Got [key=14, val=14]
> Got [key=15, val=15]
> Got [key=16, val=16]
> Got [key=17, val=17]
> Got [key=18, val=18]
> Got [key=19, val=19]
> >>> Starting putAll-getAll example.
> >>> Bulk-stored values in cache.
> Got entry [key=0, val=bulk-0]
> Got entry [key=1, val=bulk-1]
> Got entry [key=2, val=bulk-2]
> Got entry [key=3, val=bulk-3]
> Got entry [key=4, val=bulk-4]
> Got entry [key=5, val=bulk-5]
> Got entry [key=6, val=bulk-6]
> Got entry [key=7, val=bulk-7]
> Got entry [key=8, val=bulk-8]
> Got entry [key=9, val=bulk-9]
> Got entry [key=10, val=bulk-10]
> Got entry [key=11, val=bulk-11]
> Got entry [key=12, val=bulk-12]
> Got entry [key=13, val=bulk-13]
> Got entry [key=14, val=bulk-14]
> Got entry [key=15, val=bulk-15]
> Got entry [key=17, val=bulk-17]
> Got entry [key=16, val=bulk-16]
> Got entry [key=19, val=bulk-19]
> Got entry [key=18, val=bulk-18]
> [11:04:06] Ignite node stopped OK [uptime=00:00:00:254]
> {noformat}
> 4. Copy directory {{libs/optional/ignite-hibernate}} in {{libs/}}
> 5. Run CacheHibernateStoreExample. It fails with ClassNotFoundException:
> {noformat}
> c:\Work>c:\java\jdk1.7.0_80\bin\java -cp c:\Work\libs\
> *;C:\Work\libs\ignite-indexing\*;C:\Work\libs\ignite-s
> pring\*;C:\Work\libs\ignite-hibernate\* 
> org.apache.ignite.examples.datagrid.store.hiber
> nate.CacheHibernateStoreExample
> [11:06:38]__  
> [11:06:38]   /  _/ ___/ |/ /  _/_  __/ __/
> [11:06:38]  _/ // (7 7// /  / / / _/
> [11:06:38] /___/\___/_/|_/___/ /_/ /___/
> [11:06:38]
> ...
> [11:06:51] Ignite node started OK (id=16d64392)
> [11:06:51] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=3.5GB]
> >>> Cache store example started.
> [11:06:51,926][SEVERE][exchange-worker-#49%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitio
> ns (preloading will be stopped): GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], n
> odeId=16d64392, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NoClassDefFoundError: 
> org/hibernate/annotations/common/reflection/ReflectionManager
> at 
> org.apache.ignite.cache.store.hibernate.CacheHibernateStoreSessionListener.start(CacheHibernateStoreSessionLi
> stener.java:161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.startStoreSessionListeners(GridCacheUtils.java:171
> 2)
> at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.start0(GridCacheStoreManagerAd
> apter.java:213)
> at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:64)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1042)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1639
> )
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCachesStart(GridCacheProcessor.java:155
> 4)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.startCa
> ches(GridDhtPartitionsExchangeFuture.java:960)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(Gr
> 

[jira] [Created] (IGNITE-4820) Implement parallel indexes for BPlusTree

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-4820:


 Summary: Implement parallel indexes for BPlusTree
 Key: IGNITE-4820
 URL: https://issues.apache.org/jira/browse/IGNITE-4820
 Project: Ignite
  Issue Type: Sub-task
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4211:
--

[~daradurvs],

Also I found that proposed "get" method is not solving multi-threaded cache 
access issue.
In case, you proposed, method under @Cacheable annotation will be called more 
than once.

We have to use EntryProcessor (similar to Spring's JCache solution, 
https://github.com/spring-projects/spring-framework/commit/19d97c425316801a767cf99178ef30af730b1570#diff-5ce349df52238405ab1193f56a876c8f)

This way guarantee that method under @Cacheable will not be called more than 
once (EntryProcessor provides such guarantee). 



> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4819) Start .NET plugins before OnIgniteStart

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4819:


Merged to ignite-2.0

> Start .NET plugins before OnIgniteStart
> ---
>
> Key: IGNITE-4819
> URL: https://issues.apache.org/jira/browse/IGNITE-4819
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Currently we initialize and start plugins ({{IPluginProvider.Start()}}) in 
> {{OnIgniteStart}} callback. This is not correct. Java plugin part may invoke 
> callbacks from its {{start()}} method, but these callbacks are not registered 
> on .NET side yet.
> Instead, we should initialize .NET plugins in {{PluginProcessor}} ctor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-4819) Start .NET plugins before OnIgniteStart

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4819.

Resolution: Fixed

> Start .NET plugins before OnIgniteStart
> ---
>
> Key: IGNITE-4819
> URL: https://issues.apache.org/jira/browse/IGNITE-4819
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Currently we initialize and start plugins ({{IPluginProvider.Start()}}) in 
> {{OnIgniteStart}} callback. This is not correct. Java plugin part may invoke 
> callbacks from its {{start()}} method, but these callbacks are not registered 
> on .NET side yet.
> Instead, we should initialize .NET plugins in {{PluginProcessor}} ctor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-3605) Commits\rollbacks count is ZERO for transactional cache in case if the load generated by client node

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny edited comment on IGNITE-3605 at 3/14/17 2:03 PM:
-

while using any load from client node all metrics info sends through 
{code}TcpDiscoveryClientHeartbeatMessage{code} which can send only 
{code}ClusterMetrics{code} and no appropriate methods for 
{code}CacheMetrics{code}. And further 
{code}processHeartbeatMessage(TcpDiscoveryHeartbeatMessage msg){code}
sets all client nodes, server cache metrics:
{code}Map cacheMetrics = msg.hasCacheMetrics() ?
msg.cacheMetrics().get(nodeId) : 
Collections.emptyMap();
...
for (T2 t : metricsSet.clientMetrics()) {
updateMetrics(t.get1(), t.get2(), cacheMetrics, 
tstamp);{code}


was (Author: zstan):
while using any load from client node all metrics info sends through 
{code}TcpDiscoveryClientHeartbeatMessage{code} which can send only 
{code}ClusterMetrics{code} and no appropriate methods for 
{code}CacheMetrics{code}.
And further {code}processHeartbeatMessage(TcpDiscoveryHeartbeatMessage 
msg){code}
sets all client nodes, server cache metrics:
{code}Map cacheMetrics = msg.hasCacheMetrics() ?
msg.cacheMetrics().get(nodeId) : 
Collections.emptyMap();
...
for (T2 t : metricsSet.clientMetrics()) {
updateMetrics(t.get1(), t.get2(), cacheMetrics, 
tstamp);{code}

> Commits\rollbacks count is ZERO for transactional cache in case if the load 
> generated by client node 
> -
>
> Key: IGNITE-3605
> URL: https://issues.apache.org/jira/browse/IGNITE-3605
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Pavel Konstantinov
>Assignee: Stanilovsky Evgeny
>Priority: Critical
>
> Start any cluster
> Start any load via client node to transactional cache
> Take metrics from this cache and verify amount of commits and rollbacks



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4819) Start .NET plugins before OnIgniteStart

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4819:
--

 Summary: Start .NET plugins before OnIgniteStart
 Key: IGNITE-4819
 URL: https://issues.apache.org/jira/browse/IGNITE-4819
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.0


Currently we initialize and start plugins ({{IPluginProvider.Start()}}) in 
{{OnIgniteStart}} callback. This is not correct. Java plugin part may invoke 
callbacks from its {{start()}} method, but these callbacks are not registered 
on .NET side yet.

Instead, we should initialize .NET plugins in {{PluginProcessor}} ctor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4354) DML: BinaryObjectBuilder does not sort fields in some cases

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4354:
--

BinaryUtils.FIELDS_SORTED_ORDER depends on deprecated property 
IgniteSystemProperties.IGNITE_BINARY_SORT_OBJECT_FIELDS that should be removed 
in 2.0.

Is there a plan to remove this property and always use TreeMap? Or fields 
natural sort order is still needed?

> DML: BinaryObjectBuilder does not sort fields in some cases
> ---
>
> Key: IGNITE-4354
> URL: https://issues.apache.org/jira/browse/IGNITE-4354
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, SQL
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>  Labels: DML
> Fix For: 2.0
>
>
> One of the setField methods uses TreeMap<> to sort fields, depending on 
> BinaryUtils.FIELDS_SORTED_ORDER.
> However, there are other places where assignedVals is initialized (setField, 
> removeField) which are not updated to use TreeMap.
> Make sure to put this logic in one place.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-3386) Reentrant lock is lost when lock owner leaves topology

[Evgenii Zhuravlev (JIRA)]

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

Evgenii Zhuravlev resolved IGNITE-3386.
---
Resolution: Won't Fix

http://apache-ignite-developers.2346864.n4.nabble.com/IgniteSemaphore-and-failoverSafe-flag-td11945.html

> Reentrant lock is lost when lock owner leaves topology
> --
>
> Key: IGNITE-3386
> URL: https://issues.apache.org/jira/browse/IGNITE-3386
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Evgenii Zhuravlev
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
> Attachments: LockIssueVer2.java
>
>
> If to create a lock with the following configuration 
> {{IgniteLock lock = ignite.reentrantLock("lock", true, true, true);}}
> and perform the following steps below
> 1) run the first node using {{LockIssue}} that is attached;
> 2) run the second node using {{LockIssue}};
> 3) stop the first node.
> you will get the following exception on the second node side (the lock 
> information will be lost and the second node won't recreate it ignore 
> "create=true" flag):
> {code}
> SEVERE:  Failed to compare and set: 
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync$1@67aea87d
> class org.apache.ignite.IgniteCheckedException: Failed to find reentrant lock 
> with given name: test
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync$1.call(GridCacheLockImpl.java:525)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync$1.call(GridCacheLockImpl.java:518)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils$23.call(GridCacheUtils.java:1648)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:891)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.compareAndSetGlobalState(GridCacheLockImpl.java:517)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryAcquire(GridCacheLockImpl.java:400)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryAcquire(GridCacheLockImpl.java:437)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:861)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.lock(GridCacheLockImpl.java:432)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1201)
>   at 
> com.bfm.amc.loaders.server.StartIgniteServer.main(StartIgniteServer.java:15)
> {code}
> However the issue is not 100% reproduced but it should be clear from the logs 
> what happens.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-3605) Commits\rollbacks count is ZERO for transactional cache in case if the load generated by client node

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny commented on IGNITE-3605:


while using any load from client node all metrics info sends through 
{code}TcpDiscoveryClientHeartbeatMessage{code} which can send only 
{code}ClusterMetrics{code} and no appropriate methods for 
{code}CacheMetrics{code}.

> Commits\rollbacks count is ZERO for transactional cache in case if the load 
> generated by client node 
> -
>
> Key: IGNITE-3605
> URL: https://issues.apache.org/jira/browse/IGNITE-3605
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Pavel Konstantinov
>Assignee: Stanilovsky Evgeny
>Priority: Critical
>
> Start any cluster
> Start any load via client node to transactional cache
> Take metrics from this cache and verify amount of commits and rollbacks



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4761) ServiceProcessor hangs while stopping on unstable topology.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4761:
--

TC tests looks fine.

> ServiceProcessor hangs while stopping on unstable topology.
> ---
>
> Key: IGNITE-4761
> URL: https://issues.apache.org/jira/browse/IGNITE-4761
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, managed services
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
>
> GridServiceProcessor.onKernalStop can be blocked on taking busyLock when
> the lock is being held by TopologyListener while infinite waiting for 
> readyAffinityFuture.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4535) Add option to store deserialized values on-heap

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-4535:


Assignee: Ilya Lantukh

> Add option to store deserialized values on-heap
> ---
>
> Key: IGNITE-4535
> URL: https://issues.apache.org/jira/browse/IGNITE-4535
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
> Fix For: 2.0
>
>
> Now cache data is always stored in offheap (pagememory). Need implement 
> option to also store deserialised values in heap memory, this should be 
> replacement for existing CacheConfiguration.memoryMode configuration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4729) Async operation support in platform plugins

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4729:


Merged with ignite-2.0. [~vozerov], please have a look.

> Async operation support in platform plugins
> ---
>
> Key: IGNITE-4729
> URL: https://issues.apache.org/jira/browse/IGNITE-4729
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Expose a set of async operations on {{IPlatformTarget}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4716) .NET: Add IgniteUuid system type support

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4716:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-4716 .NET: Add IgniteUuid system type support



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

$ git pull https://github.com/ptupitsyn/ignite ignite-4716

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

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


commit 15633ac76aaa0ec95d581da9263f74cc57b21cc5
Author: Pavel Tupitsyn 
Date:   2017-03-14T10:57:47Z

Implement read/write

commit baae98636b9b9087a9db038bc27c6a268331174b
Author: Pavel Tupitsyn 
Date:   2017-03-14T11:07:13Z

register system type

commit b0d5649643d5bd12414fde75699a01aa99771730
Author: Pavel Tupitsyn 
Date:   2017-03-14T11:14:40Z

restore serializable attr to fix collections handling

commit c719ae62c7bfe275a6f7f850d5bd2704fca02f38
Author: Pavel Tupitsyn 
Date:   2017-03-14T11:22:58Z

Refactor events read/write

commit f0d8c86a758679699ca85183d9b33c80913749e4
Author: Pavel Tupitsyn 
Date:   2017-03-14T11:37:23Z

Fix type id

commit 1bcfbfa1c24cff438819f461fffa3657055b8178
Author: Pavel Tupitsyn 
Date:   2017-03-14T11:43:16Z

wip tests

commit 124c6bc5f44e62a60c52f26c9f27e958a2317ba7
Author: Pavel Tupitsyn 
Date:   2017-03-14T11:44:14Z

wip tests

commit 7accf119cae8163638569339bb0889fde83a3a4d
Author: Pavel Tupitsyn 
Date:   2017-03-14T11:58:07Z

Fix raw pos




> .NET: Add IgniteUuid system type support
> 
>
> Key: IGNITE-4716
> URL: https://issues.apache.org/jira/browse/IGNITE-4716
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> IGNITE-4611 makes it possible to handle {{IgniteUuid}} on .NET side as a 
> first class binary object instead of a special case. Make sure to refactor 
> current usages.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4587) Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-4587 at 3/14/17 11:29 AM:
---

[~dreamx],

I've review your changes. See my comments below. Please, fix.

# Class {{GridCacheAtomicFullApiSelfTest}}: method {{cacheConfiguration()}} can 
be removed because it just returns result of base class method.
# Class {{GridCacheAtomicMultiNodeP2PDisabledFullApiSelfTest}}: method 
{{cacheConfiguration()}} can be removed because it just returns result of base 
class method.
# Class {{GridCacheReplicatedAtomicMultiNodeFullApiSelfTest}}: method 
{{cacheConfiguration()}} can be removed because it just returns result of base 
class method.
# Class {{GridCacheAtomicMessageCountSelfTest}}: methods 
{{testPartitionedPrimary()}} and {{testClientPrimary()}} should be renamed to 
{{testPartitioned()}} and {{testClient()}} respectively.
# Class {{GridCacheAtomicNearCacheSelfTest}}: method {{startGridsLocal()}} 
confuses. Why {{Local}}? May be {{doStartGrids}} or something like.
# Class {{GridCacheAtomicVersionComparator}}: {{ignoreTime}} parameter at 
{{compare}} method is unused and should be removed.
# Class {{GridCacheInterceptorAbstractSelfTest}}: unused import and methods.
# Class {{GridCacheMapEntry}}, method {{innerUpdate}}, lines 2172 and 2228: 
{{ignireTime}} variable is always {{true}}. Need remove usage.
# Class {{GridCacheMultithreadedFailoverAbstractTest}}, method 
{{configuration()}}, line 221: Nested if could be combined with embraced.
# Class {{GridCacheUtils}}: unused imports.
# Class {{GridCacheUtils}}: Bug. Please fix array size and offsets in 
{{versionToBytes()}} and {{readVersion()}} methods.
# Class {{IgniteUtils}}: Bug. Please fix offsets in {{writeVersion()}} and 
{{readVersion()}} methods.
# Class {{GridCacheVersion}}: Bug. Integers will be overflowed in 
{{asGridUuid()}} method. Please replace by {{new UUID(topVer, nodeOrderDrId)}}.
# Class {{GridCacheVersion}}: method {{fieldsCount()}} returns incorrect 
result. Use {{MessageCodeGenerator}} in order to generate correct code.
# Class {{GridCacheVersionEx}}: incorrect implementations of {{fieldsCount()}}, 
{{writeTo()}} and {{readFrom()}} methods. Use {{MessageCodeGenerator}} in order 
to generate correct code.
# Class {{GridCommonAbstractTest}}: unused imports.
# Class {{GridCommonAbstractTest}}: method {{atomicClockModeDelay()}} should be 
removed.
# Class {{GridDhtAtomicCache}}: I'm not sure about it. It seems that methos 
{{isFastMap()}} should not be removed. Could you please ask about it on dev 
list. Check also {{fastMap}} flag in {{GridNearAtomicUpdateFuture}} class.
# Class {{GridDhtAtomicCache}}: Redundant {{catch}} blocks in 
{{lockEntriesMethod()}}, lines 2899 and 2914.
# Class {{GridNearAtomicSingleUpdateFuture}}: Method {{mapSingleUpdate()}} 
creates different requests (like {{GridNearAtomicSingleUpdateInvokeRequest}}). 
For all this requests all instantiations have {{updateVer == null}}. Need to 
remove this prameter. The same for {{GridNearAtomicUpdateFuture}} class 
{{mapUpdate()}} and {{mapSingleUpdate()}} methods.
# Class {{IgniteBenchmarkArguments}}: Comand line arguments {{"-wom", 
"--writeOrderMode"}} were removed. Please, check that there are not this 
arguments usges in {{modules/yardstick}}.
# Class {{IgniteCacheExpiryPolicyAbstractTest}}: methods {{nearReaderUpdate()}} 
and {{nearPutAll()}}. It seems that all {{U.sleep()}} calls are redundant now.
# Class {{IgniteCachePutRetryAbstractSelfTest}}: unused import.
# Class {{IgniteConfiguration}}: fields {{clockSyncSamples}} and 
{{clockSyncFreq}}, corresponding methods and constants 
{{DFLT_CLOCK_SYNC_SAMPLES}} and {{DFLT_CLOCK_SYNC_FREQUENCY}} should be removed.

Also I see a lot of removed tests. I need additional time for analyzing it. 
Thanks!


was (Author: agura):
[~dreamx],

I've review your changes. See my comments below. Please, fix.

# Class {{GridCacheAtomicFullApiSelfTest}}: method {{cacheConfiguration()}} can 
be removed because it just returns result of base class method.
# Class {{GridCacheAtomicMultiNodeP2PDisabledFullApiSelfTest}}: method 
{{cacheConfiguration()}} can be removed because it just returns result of base 
class method.
# Class {{GridCacheReplicatedAtomicMultiNodeFullApiSelfTest}}: method 
{{cacheConfiguration()}} can be removed because it just returns result of base 
class method.
# Class {{GridCacheAtomicMessageCountSelfTest}}: methods 
{{testPartitionedPrimary()}} and {{testClientPrimary()}} should be renamed to 
{{testPartitioned()}} and {{testClient()}} respectively.
# Class {{GridCacheAtomicNearCacheSelfTest}}: method {{startGridsLocal()}} 
confuses. Why {{Local}}? May be {{doStartGrids}} or something like.
# Class {{GridCacheAtomicVersionComparator}}: {{ignoreTime}} parameter at 
{{compare}} method is unused and should be removed.
# Class 

[jira] [Comment Edited] (IGNITE-4587) Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-4587 at 3/14/17 11:29 AM:
---

[~dreamx],

I've review your changes. See my comments below. Please, fix.

# Class {{GridCacheAtomicFullApiSelfTest}}: method {{cacheConfiguration()}} can 
be removed because it just returns result of base class method.
# Class {{GridCacheAtomicMultiNodeP2PDisabledFullApiSelfTest}}: method 
{{cacheConfiguration()}} can be removed because it just returns result of base 
class method.
# Class {{GridCacheReplicatedAtomicMultiNodeFullApiSelfTest}}: method 
{{cacheConfiguration()}} can be removed because it just returns result of base 
class method.
# Class {{GridCacheAtomicMessageCountSelfTest}}: methods 
{{testPartitionedPrimary()}} and {{testClientPrimary()}} should be renamed to 
{{testPartitioned()}} and {{testClient()}} respectively.
# Class {{GridCacheAtomicNearCacheSelfTest}}: method {{startGridsLocal()}} 
confuses. Why {{Local}}? May be {{doStartGrids}} or something like.
# Class {{GridCacheAtomicVersionComparator}}: {{ignoreTime}} parameter at 
{{compare}} method is unused and should be removed.
# Class {{GridCacheInterceptorAbstractSelfTest}}: unused import and methods.
# Class {{GridCacheMapEntry}}, method {{innerUpdate}}, lines 2172 and 2228: 
{{ignireTime}} variable is always {{true}}. Need remove usage.
# Class {{GridCacheMultithreadedFailoverAbstractTest}}, method 
{{configuration()}}, line 221: Nested if could be combined with embraced.
# Class {{GridCacheUtils}}: unused imports.
# Class {{GridCacheUtils}}: Bug. Please fix array size and offsets in 
{{versionToBytes()}} and {{readVersion()}} methods.
# Class {{IgniteUtils}}: Bug. Please fix offsets in {{writeVersion()}} and 
{{readVersion()}} methods.
# Class {{GridCacheVersion}}: Bug. Integers will be overflowed in 
{{asGridUuid()}} method. Please replace by {{new UUID(topVer, nodeOrderDrId)}}.
# Class {{GridCacheVersion}}: method {{fieldsCount()}} returns incorrect 
result. Use {{MessageCodeGenerator}} in order to generate correct code.
# Class {{GridCacheVersionEx}}: incorrect implementations of {{fieldsCount()}}, 
{{writeTo()}} and {{readFrom()}} methods. Use {{MessageCodeGenerator}} in order 
to generate correct code.
# Class {{GridCommonAbstractTest}}: unused imports.
# Class {{GridCommonAbstractTest}}: method {{atomicClockModeDelay()}} should be 
removed.
# Class {{GridDhtAtomicCache}}: I'm not sure about it. It seems that methos 
{{isFastMap()}} should not be removed. Could you please ask about it on dev 
list. Check also {{fastMap}} flag in {{GridNearAtomicUpdateFuture}} class.
# Class {{GridDhtAtomicCache}}: Redundant {{catch}} blocks in 
{{lockEntriesMethod()}}, lines 2899 and 2914.
# Class {{GridNearAtomicSingleUpdateFuture}}: Method {{mapSingleUpdate()}} 
creates different requests (like {{GridNearAtomicSingleUpdateInvokeRequest}}). 
For all this requests all instantiations have {{updateVer == null}}. Need to 
remove this prameter. The same for {{GridNearAtomicUpdateFuture}} class 
{{mapUpdate()}} and {{mapSingleUpdate()}} methods.
# Class {{IgniteBenchmarkArguments}}: Comand line arguments {{"-wom", 
"--writeOrderMode"}} were removed. Please, check that there are not this 
arguments usges in {{modules/yardstick}}.
# Class {{IgniteCacheExpiryPolicyAbstractTest}}: methods {{nearReaderUpdate()}} 
and {{nearPutAll()}}. It seems that all {{U.sleep()}} calls are redundant now.
# Class {{IgniteCachePutRetryAbstractSelfTest}}: unused import.
# Class {{IgniteConfiguration}}: fields {{clockSyncSamples}} and 
{{clockSyncFreq}}, corresponding methods and constants 
{{DFLT_CLOCK_SYNC_SAMPLES}} and {{DFLT_CLOCK_SYNC_FREQUENCY}} should be removed.
# Class {{IgniteSystemProperties}}: 

Also I see a lot of removed tests. I need additional time for analyzing it. 
Thanks!


was (Author: agura):
[~dreamx],

I've review your changes. See my comments below. Please, fix.

# Class {{GridCacheAtomicFullApiSelfTest}}: method {{cacheConfiguration()}} can 
be removed because it just returns result of base class method.
# Class {{GridCacheAtomicMultiNodeP2PDisabledFullApiSelfTest}}: method 
{{cacheConfiguration()}} can be removed because it just returns result of base 
class method.
# Class {{GridCacheReplicatedAtomicMultiNodeFullApiSelfTest}}: method 
{{cacheConfiguration()}} can be removed because it just returns result of base 
class method.
# Class {{GridCacheAtomicMessageCountSelfTest}}: methods 
{{testPartitionedPrimary()}} and {{testClientPrimary()}} should be renamed to 
{{testPartitioned()}} and {{testClient()}} respectively.
# Class {{GridCacheAtomicNearCacheSelfTest}}: method {{startGridsLocal()}} 
confuses. Why {{Local}}? May be {{doStartGrids}} or something like.
# Class {{GridCacheAtomicVersionComparator}}: {{ignoreTime}} parameter at 
{{compare}} method is 

[jira] [Resolved] (IGNITE-4747) Memory leak on massive cache operations over atomic cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov resolved IGNITE-4747.
---
Resolution: Cannot Reproduce

This issue does not reproduced in a latest version.

> Memory leak on massive cache operations over atomic cache
> -
>
> Key: IGNITE-4747
> URL: https://issues.apache.org/jira/browse/IGNITE-4747
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: Heap Histogram.mht, invoke-fill.zip
>
>
> When starts several nodes (I have tested in 4 nodes) with the application, 
> through some time (depends of heap size), we have got a Full GC pause and 
> segmentation the grid.
> After heap dump analysis, I found some suspicious object:
>   ||Class|| Instance Count|| Total Size 
> |class java.util.concurrent.ConcurrentSkipListMap$Node| 63622411|   
> 1526937864  
> |class java.util.concurrent.ConcurrentSkipListMap$Index|  31810595|   
> 763454280  
> |class java.lang.Long|
>  63622318|508978544  
> the leak in the field {{updates}} of class {{GridDhtLocalPartition}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-3018:


Assignee: Taras Ledkov  (was: Yakov Zhdanov)

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: 003.png, 064.png, 100.png, 128.png, 200.png, 300.png, 
> 400.png, 500.png, 600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4551) Reconsider cache key/value peer class loading

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov reassigned IGNITE-4551:


Assignee: Nikolay Tikhonov

> Reconsider cache key/value peer class loading
> -
>
> Key: IGNITE-4551
> URL: https://issues.apache.org/jira/browse/IGNITE-4551
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Tikhonov
> Fix For: 2.0
>
>
> In new cache implementation after entry is written in offheap information 
> about key/value classloaders in lost (before classloader ids were stored in 
> swap/offheap see GridCacheMapEntry.swap in 'master').
> Need decide how it should work with new architecture (maybe single type per 
> cache can simplify implementation).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4716) .NET: Add IgniteUuid system type support

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4716:
--

Assignee: Pavel Tupitsyn

> .NET: Add IgniteUuid system type support
> 
>
> Key: IGNITE-4716
> URL: https://issues.apache.org/jira/browse/IGNITE-4716
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> IGNITE-4611 makes it possible to handle {{IgniteUuid}} on .NET side as a 
> first class binary object instead of a special case. Make sure to refactor 
> current usages.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4012) Compile issues with v1.7.0/1.8.0 - missing dependency & H2 issue

[Malaury TCHERKACHINE (JIRA)]

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

Malaury TCHERKACHINE commented on IGNITE-4012:
--

if you copy the missing jars into your local repository it work.

The missing jars are located in (and pom.xml) : 
ignite/modules/core/src/test/binaries/repo/org/apache/ignite/binary/test1/1.1/
ignite/modules/core/src/test/binaries/repo/org/apache/ignite/binary/test2/1.1/

copy to : 
~/maven-repository/org/apache/ignite/binary/test1/1.1/
~/maven-repository/org/apache/ignite/binary/test2/1.1/

I hope you will be able to compile the project now..

> Compile issues with v1.7.0/1.8.0 - missing dependency & H2 issue
> 
>
> Key: IGNITE-4012
> URL: https://issues.apache.org/jira/browse/IGNITE-4012
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.7, 1.8
>Reporter: Steve White
>
> Hi, I'd just like to mention a couple of build issues - not sure if you're 
> aware. 
> If I build Apache Ignite tags/1.7.0 (1.7.0-SNAPSHOT) & master 
> (1.8.0-SNAPSHOT) I get:
> {code}
> Missing dependencies:
> [ERROR] Failed to execute goal on project ignite-core: Could not resolve 
> dependencies for project org.apache.ignite:ignite-core:jar:1.7.0-SNAPSHOT: 
> The following artifacts could not be resolved: 
> org.apache.ignite.binary:test1:jar:1.1, 
> org.apache.ignite.binary:test2:jar:1.1:
> {code}
> If I comment the ignite-core:test1,test2 dependencies out I get a bunch of 
> compile time errors in the indexing module referencing h2, just to mention a 
> couple:
> {code}
> GridMergeIndex.java:[298,16] method getCostRangeIndex in class 
> org.h2.index.BaseIndex cannot be applied to given types;
> [ERROR] required: 
> int[],long,org.h2.table.TableFilter[],int,org.h2.result.SortOrder,boolean,java.util.HashSet
> [ERROR] found: 
> int[],long,org.h2.table.TableFilter[],int,org.h2.result.SortOrder,boolean
> [ERROR] reason: actual and formal argument lists differ in length
> GridH2TreeIndex.java:[49,8] 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex is not 
> abstract and does
>  not override abstract method 
> getCost(org.h2.engine.Session,int[],org.h2.table.TableFilter[],int,org.h2.result.SortOrder,java.util.HashSet)
>  in org.h2.index.Index
> {code}
> Restricting building a subset of modules works, e.g:
> {code}
> mvn clean install -DskipTests -Dmaven.javadoc.skip=true -pl 
> modules/apache-license-gen,modules/tools,modules/core,modules/osgi,modules/spring,modules/slf4j
> {code}
> But I really need indexing. My next step is to be drop the pom to an earlier 
> version of H2 to try get it built. My reasons for building from source are to 
> include a number of additional OSGi package imports (TBC).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4816) Issue with refresh rate on queries

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-4816:


Reviewed. Looks good for me. [~pkonstantinov], can you please check?

> Issue with refresh rate on queries
> --
>
> Key: IGNITE-4816
> URL: https://issues.apache.org/jira/browse/IGNITE-4816
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>
> Next query execution start before previous one is finished



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4818) .NET DayOfWeek does not work as a LINQ parameter

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4818:
--

 Summary: .NET DayOfWeek does not work as a LINQ parameter
 Key: IGNITE-4818
 URL: https://issues.apache.org/jira/browse/IGNITE-4818
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.9
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.0


IGNITE-4359 added support for {{DateTime.DayOfWeek}}, but it can't be used in 
Where clause:

{code}
var res = persons.AsCacheQueryable().Where(x => x.Value.BirthDay.DayOfWeek == 
DayOfWeek.Monday);
{code}

This fails because {{DayOfWeek.Monday}} is written as a serializable enum.

Workaround is to cast to an int:

{code}
var res = persons.AsCacheQueryable().Where(x => (int)x.Value.BirthDay.DayOfWeek 
== (int)DayOfWeek.Monday);
{code}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-4817) .NET: Contains fails in LINQ when subquery comes from a variable

[Pavel Tupitsyn (JIRA)]

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

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

> .NET: Contains fails in LINQ when subquery comes from a variable
> 
>
> Key: IGNITE-4817
> URL: https://issues.apache.org/jira/browse/IGNITE-4817
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Minor
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> Using Contains with subquery works when subquery is inline:
> {code}
> var res = personsQry.Where(x => orgsQry.Where(o => o.Value.Size < 
> 10).Select(o => o.Key).Contains(x.Value.OrgId));
> {code}
> And fails when extracted into a variable:
> {code}
> var orgIds = orgsQry.Where(o => o.Value.Size < 10).Select(o => o.Key);
>   
> var res = personsQry.Where(x => orgIds.Contains(x.Value.OrgId));
> {code}
> Exception:
> {code}
> Failed to parse query: select _T0._key, _T0._val from "persons-linq".Person 
> as _T0 where (_T0.OrgId IN (select _T1._key, _T1._val from 
> "orgs-linq".Organization as _T1 ))
> {code}
> This can be reproduced in {{CacheLinqTest.TestContains}} by extracting a 
> variable:
> {code}
> var foo = orgCache
>   .Where(orgEntry => orgEntry.Value.Name == "Org_1")
>   .Select(orgEntry => orgEntry.Key);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4817) .NET: Contains fails in LINQ when subquery comes from a variable

[Sergey Stronchinskiy (JIRA)]

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

Sergey Stronchinskiy reassigned IGNITE-4817:


Assignee: Sergey Stronchinskiy

> .NET: Contains fails in LINQ when subquery comes from a variable
> 
>
> Key: IGNITE-4817
> URL: https://issues.apache.org/jira/browse/IGNITE-4817
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> Using Contains with subquery works when subquery is inline:
> {code}
> var res = personsQry.Where(x => orgsQry.Where(o => o.Value.Size < 
> 10).Select(o => o.Key).Contains(x.Value.OrgId));
> {code}
> And fails when extracted into a variable:
> {code}
> var orgIds = orgsQry.Where(o => o.Value.Size < 10).Select(o => o.Key);
>   
> var res = personsQry.Where(x => orgIds.Contains(x.Value.OrgId));
> {code}
> Exception:
> {code}
> Failed to parse query: select _T0._key, _T0._val from "persons-linq".Person 
> as _T0 where (_T0.OrgId IN (select _T1._key, _T1._val from 
> "orgs-linq".Organization as _T1 ))
> {code}
> This can be reproduced in {{CacheLinqTest.TestContains}} by extracting a 
> variable:
> {code}
> var foo = orgCache
>   .Where(orgEntry => orgEntry.Value.Name == "Org_1")
>   .Select(orgEntry => orgEntry.Key);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4667) Throw exception on starting client cache when indexed types cannot be loaded

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-4667:
---

Assignee: Dmitry Karachentsev

> Throw exception on starting client cache when indexed types cannot be loaded
> 
>
> Key: IGNITE-4667
> URL: https://issues.apache.org/jira/browse/IGNITE-4667
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>
> Assume following situation:
> 1. Server node configured cache indexed types with classes that client node 
> doesn't have.
> 2. Start server.
> 3. Start client. Client successfully connected.
> 4. Try to get cache on client node.
> 5. Was thrown exception in GridQueryProcessor and request for cache on client 
> node hangs forever.
> If on some reason cache couldn't be initialized, exception must be thrown on 
> Ignite.cache() operation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4337) Introduce persistence interface to allow build reliable persistence plugins

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-4337:


Assignee: Alexey Goncharuk

> Introduce persistence interface to allow build reliable persistence plugins
> ---
>
> Key: IGNITE-4337
> URL: https://issues.apache.org/jira/browse/IGNITE-4337
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 2.0
>
>
> With page memory interface introduced, it may be possible to build a 
> persistence layer around this architecture. I think we should move the 
> PageMemory interface itself to {{org.apache.ignite.plugin.storage}} package 
> and introduce the following interface to allow other components to log it's 
> activity in crash-resistant way:
> {code}
> /**
>  *
>  */
> public interface IgniteWriteAheadLogManager extends GridCacheSharedManager {
> /**
>  * @return {@code true} If we have to always write full pages.
>  */
> public boolean isAlwaysWriteFullPages();
> /**
>  * @return {@code true} if WAL will perform fair syncs on fsync call.
>  */
> public boolean isFullSync();
> /**
>  * Resumes logging after start. When WAL manager is started, it will skip 
> logging any updates until this
>  * method is called to avoid logging changes induced by the state restore 
> procedure.
>  */
> public void resumeLogging(WALPointer lastWrittenPtr) throws 
> IgniteCheckedException;
> /**
>  * Appends the given log entry to the write-ahead log.
>  *
>  * @param entry entry to log.
>  * @return WALPointer that may be passed to {@link #fsync(WALPointer)} 
> method to make sure the record is
>  *  written to the log.
>  * @throws IgniteCheckedException If failed to construct log entry.
>  * @throws StorageException If IO error occurred while writing log entry.
>  */
> public WALPointer log(WALRecord entry) throws IgniteCheckedException, 
> StorageException;
> /**
>  * Makes sure that all log entries written to the log up until the 
> specified pointer are actually persisted to
>  * the underlying storage.
>  *
>  * @param ptr Optional pointer to sync. If {@code null}, will sync up to 
> the latest record.
>  * @throws IgniteCheckedException If
>  * @throws StorageException
>  */
> public void fsync(WALPointer ptr) throws IgniteCheckedException, 
> StorageException;
> /**
>  * Invoke this method to iterate over the written log entries.
>  *
>  * @param start Optional WAL pointer from which to start iteration.
>  * @return Records iterator.
>  * @throws IgniteException If failed to start iteration.
>  * @throws StorageException If IO error occurred while reading WAL 
> entries.
>  */
> public WALIterator replay(WALPointer start) throws 
> IgniteCheckedException, StorageException;
> /**
>  * Gives a hint to WAL manager to clear entries logged before the given 
> pointer. Some entries before the
>  * the given pointer will be kept because there is a configurable WAL 
> history size. Those entries may be used
>  * for partial partition rebalancing.
>  *
>  * @param ptr Pointer for which it is safe to clear the log.
>  * @return Number of deleted WAL segments.
>  */
> public int truncate(WALPointer ptr);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-4806) Infinite classLoading discovery process

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny reassigned IGNITE-4806:
--

Assignee: Alexei Scherbakov  (was: Stanilovsky Evgeny)

plz review this PR

> Infinite classLoading discovery process
> ---
>
> Key: IGNITE-4806
> URL: https://issues.apache.org/jira/browse/IGNITE-4806
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.8
>Reporter: Stanilovsky Evgeny
>Assignee: Alexei Scherbakov
>Priority: Minor
> Attachments: reproduce.tar.gz
>
>
> Hello, i found infinite discovery class loading after very rare usage case.
> In a nutshell to reproduce we need to run sequentially 3 different jvm 
> instances.
> FirstNode instance simple start the grid.
> SecondNode connect to grid, initialize custom classLoader, and run 
> IgniteCallable (JobA) wrapped into ComputeTask instance.
> ThirdNode  connect to grid, initialize custom classLoader, and run two 
> IgniteCallable (JobB, jobB2) wrapped into ComputeTask instances.
> Finally we can observe JobA has been running in First and Second nodes, JobB  
> has been running in First, Second and Third nodes, while jobB2 starts 
> infinite class loading. We could see it simply looking into First Node thread 
> dump:
> {code}
> "pub-#69%grid%" prio=10 tid=0x7f9218015800 nid=0x3de5 runnable 
> [0x7f9254176000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.Throwable.fillInStackTrace(Native Method)
>   at java.lang.Throwable.fillInStackTrace(Throwable.java:783)
>   - locked <0x0007d43ced00> (a java.lang.ClassNotFoundException)
>   at java.lang.Throwable.(Throwable.java:287)
>   at java.lang.Exception.(Exception.java:84)
>   at 
> java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:75)
>   at 
> java.lang.ClassNotFoundException.(ClassNotFoundException.java:82)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>   - locked <0x00070c22fd08> (a java.lang.Object)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:278)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getLocalDeployment(GridDeploymentManager.java:383)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.findClass(GridDeploymentClassLoader.java:497)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>   - locked <0x00070c0361e0> (a 
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.loadClass(GridDeploymentClassLoader.java:441)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:278)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeployment.deployedClass(GridDeployment.java:444)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.getDeployment(GridDeploymentPerVersionStore.java:454)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:494)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:982)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:710)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:102)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:673)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-4806) Infinite classLoading discovery process

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4806:


GitHub user zstan opened a pull request:

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

IGNITE-4806 Fix infinite classloading discovery



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

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

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

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


commit c2b41d8bb3cdb9bb4aa60b42904162f75bb89a11
Author: Evgeny Stanilovskiy 
Date:   2017-03-09T13:54:02Z

IGNITE-4806 Fix infinite classloading discovery




> Infinite classLoading discovery process
> ---
>
> Key: IGNITE-4806
> URL: https://issues.apache.org/jira/browse/IGNITE-4806
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.8
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Attachments: reproduce.tar.gz
>
>
> Hello, i found infinite discovery class loading after very rare usage case.
> In a nutshell to reproduce we need to run sequentially 3 different jvm 
> instances.
> FirstNode instance simple start the grid.
> SecondNode connect to grid, initialize custom classLoader, and run 
> IgniteCallable (JobA) wrapped into ComputeTask instance.
> ThirdNode  connect to grid, initialize custom classLoader, and run two 
> IgniteCallable (JobB, jobB2) wrapped into ComputeTask instances.
> Finally we can observe JobA has been running in First and Second nodes, JobB  
> has been running in First, Second and Third nodes, while jobB2 starts 
> infinite class loading. We could see it simply looking into First Node thread 
> dump:
> {code}
> "pub-#69%grid%" prio=10 tid=0x7f9218015800 nid=0x3de5 runnable 
> [0x7f9254176000]
>java.lang.Thread.State: RUNNABLE
>   at java.lang.Throwable.fillInStackTrace(Native Method)
>   at java.lang.Throwable.fillInStackTrace(Throwable.java:783)
>   - locked <0x0007d43ced00> (a java.lang.ClassNotFoundException)
>   at java.lang.Throwable.(Throwable.java:287)
>   at java.lang.Exception.(Exception.java:84)
>   at 
> java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:75)
>   at 
> java.lang.ClassNotFoundException.(ClassNotFoundException.java:82)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>   - locked <0x00070c22fd08> (a java.lang.Object)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:278)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getLocalDeployment(GridDeploymentManager.java:383)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.findClass(GridDeploymentClassLoader.java:497)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>   - locked <0x00070c0361e0> (a 
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.loadClass(GridDeploymentClassLoader.java:441)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:278)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeployment.deployedClass(GridDeployment.java:444)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.getDeployment(GridDeploymentPerVersionStore.java:454)
>   at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:494)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:982)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
>   at 
>