[jira] [Commented] (IGNITE-8463) Node.js: setup TeamCity

[ekaterina.vergizova (JIRA)]

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

ekaterina.vergizova commented on IGNITE-8463:
-

The TLS test is successfully passed locally.
I use the following IgniteConfiguration to run it:
 
 


 
 
 
 
 
 
 
 


 
 
 
 
 
 


 
 
 
 
 
 
 
 
 
 

Probably you lose keyStorePassword and trustStorePassword properties and may be 
something else.

> Node.js: setup TeamCity
> ---
>
> Key: IGNITE-8463
> URL: https://issues.apache.org/jira/browse/IGNITE-8463
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
>
> Minimal implementation of NodeJS client is almost ready (IGNITE-8014). We 
> need to figure out how to integrate it with TeamCity:
> 1) New suite for NodeJS is needed along with required environment (npm, any 
> recent version). 2) Suite should be able to run Jasmine tests [1]
> 3) Currently all tests rely on manually started external node. We need to 
> create a set of scripts (bash?) to start/stop nodes locally from Jasmine. Raw 
> suggestion: call {{ignite.sh}} with predefined configuration.
> [1] https://jasmine.github.io/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8304) Document failures handing in Ignite

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-8304:
-

Reviewed and made minor edits.

> Document failures handing in Ignite
> ---
>
> Key: IGNITE-8304
> URL: https://issues.apache.org/jira/browse/IGNITE-8304
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> IEP-14: 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling
> The following failures will be treated as critical and can lead to an 
> automatic node termination depending on configuration:
> * System critical errors (e.g. OutOfMemoryError);
> * Unintentional system worker termination (e.g. due to an unhandled 
> exception);
> * Cluster node segmentation.
> In addition to that, the doc should cover how to utilize JVM pauses detector: 
> https://issues.apache.org/jira/browse/IGNITE-6171



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-8304) Document failures handing in Ignite

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-8304.
---

> Document failures handing in Ignite
> ---
>
> Key: IGNITE-8304
> URL: https://issues.apache.org/jira/browse/IGNITE-8304
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> IEP-14: 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling
> The following failures will be treated as critical and can lead to an 
> automatic node termination depending on configuration:
> * System critical errors (e.g. OutOfMemoryError);
> * Unintentional system worker termination (e.g. due to an unhandled 
> exception);
> * Cluster node segmentation.
> In addition to that, the doc should cover how to utilize JVM pauses detector: 
> https://issues.apache.org/jira/browse/IGNITE-6171



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8550:
--

 Summary: CacheAbstractJdbcStore expects merge to always return 1 
but MySQL may also return 2 or 0
 Key: IGNITE-8550
 URL: https://issues.apache.org/jira/browse/IGNITE-8550
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Stanislav Lukyanov


CacheAbstractJdbcStore.write attempts to execute a merge update if it is 
available, and expects the merge to always return 1 (as the number of updated 
entries is always 1).

However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE` 
(https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return 0 
or 2, depending on what was updated:
{quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if 
the row is inserted as a new row, 2 if an existing row is updated, and 0 if an 
existing row is set to its current values.{quote}
Because of that, CacheAbstractJdbcStore may report a false warning.

Need to consider either removing the warning or special-case the MySQL dialect 
to allow to return values other than 1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-8241) Docs: Triggering automatic rebalancing if the whole baseline topology is not recovered

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-8241.
---

> Docs: Triggering automatic rebalancing if the whole baseline topology is not 
> recovered
> --
>
> Key: IGNITE-8241
> URL: https://issues.apache.org/jira/browse/IGNITE-8241
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.5
>
> Attachments: BaselineWatcher.java
>
>
> The ticket is created as a result of the following discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Triggering-rebalancing-on-timeout-or-manually-if-the-baseline-topology-is-not-reassembled-td29299.html
> The rebalancing doesn't happen if one of the nodes goes down, 
> thus, shrinking the baseline topology. It complies with our assumption that 
> the node should be recovered soon and there is no need to waste 
> CPU/memory/networking resources of the cluster shifting the data around. 
> However, there are always edge cases. I was reasonably asked how to trigger 
> the rebalancing within the baseline topology manually or on timeout if: 
> * It's not expected that the failed node would be resurrected in the 
>nearest time and 
> * It's not likely that that node will be replaced by the other one. 
> Until we embedd special facilities in the baseline topology that would 
> consider such situations we can document the following workaround. A user 
> application/tool/script has to subscribe to node_left events and remove the 
> failed node from the baseline topology in some time. Once the node is 
> removed, the baseline topology will be changed, and the rebalancing will be 
> kicked off.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8241) Docs: Triggering automatic rebalancing if the whole baseline topology is not recovered

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-8241:
-

Reviewed.

> Docs: Triggering automatic rebalancing if the whole baseline topology is not 
> recovered
> --
>
> Key: IGNITE-8241
> URL: https://issues.apache.org/jira/browse/IGNITE-8241
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.5
>
> Attachments: BaselineWatcher.java
>
>
> The ticket is created as a result of the following discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Triggering-rebalancing-on-timeout-or-manually-if-the-baseline-topology-is-not-reassembled-td29299.html
> The rebalancing doesn't happen if one of the nodes goes down, 
> thus, shrinking the baseline topology. It complies with our assumption that 
> the node should be recovered soon and there is no need to waste 
> CPU/memory/networking resources of the cluster shifting the data around. 
> However, there are always edge cases. I was reasonably asked how to trigger 
> the rebalancing within the baseline topology manually or on timeout if: 
> * It's not expected that the failed node would be resurrected in the 
>nearest time and 
> * It's not likely that that node will be replaced by the other one. 
> Until we embedd special facilities in the baseline topology that would 
> consider such situations we can document the following workaround. A user 
> application/tool/script has to subscribe to node_left events and remove the 
> failed node from the baseline topology in some time. Once the node is 
> removed, the baseline topology will be changed, and the rebalancing will be 
> kicked off.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-8133) Baseline topology documentation improvement

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-8133.
---

> Baseline topology documentation improvement
> ---
>
> Key: IGNITE-8133
> URL: https://issues.apache.org/jira/browse/IGNITE-8133
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.5
>
> Attachments: blt_guide.md
>
>
> Baseline topology concept was added to Ignite in 2.4 by IEP-4. This changed 
> Ignite cluster behavior when persistence is enabled (first of all, activation 
> and rebalancing timings).
> It seems that the current documentation may be confusing.
> For example, the sentence
> {quote}Note that the baseline topology is not set when the cluster is started 
> for the first time; that's the only time when a manual intervention is 
> needed.{quote}
> may lead one to think that baseline topology is not used by default and needs 
> to be enabled only if one wants to use it.
> Also, the documentation describes the tools and commands that are used to 
> manage the baseline topology and activation, but doesn't give guidelines on 
> which nodes should be in the topology, when should it be changed, etc.
> The documentation should be enhanced to
> - give clear understanding that baseline topology always needs to be 
> considered as a part of the cluster architecture when persistence is enabled;
> - provide overview of the behavioral changes compared to AI 2.3 (use a 
> note/warning block for that to separate it from the main text?);
> - provide basic guidelines and suggestions of how one can start a new cluster 
> and manage it (when to activate/deactivate, when to change baseline topology, 
> what happens and what needs to be done when a node fails or joins, how to use 
> consistentId)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8549) Include SSL related parameters for JDBC/ODBC

[Prachi Garg (JIRA)]

Prachi Garg created IGNITE-8549:
---

 Summary: Include SSL related parameters for JDBC/ODBC
 Key: IGNITE-8549
 URL: https://issues.apache.org/jira/browse/IGNITE-8549
 Project: Ignite
  Issue Type: Task
Reporter: Prachi Garg
Assignee: Prachi Garg
 Fix For: 2.5


DRIVER=\{Apache 
Ignite};ADDRESS=13.56.76.37:9954;USER=ignite;PASSWORD=1mSBcc8loX;*SSL_MODE=require;SSL_KEY_FILE=client.pem;SSL_CERT_FILE=client.pem;SSL_CA_FILE=client.pem*
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8514) Missed descriptions for a few packages in Javadoc

[Andrey Gura (JIRA)]

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

Andrey Gura reassigned IGNITE-8514:
---

Assignee: (was: Andrey Gura)

> Missed descriptions for a few packages in Javadoc
> -
>
> Key: IGNITE-8514
> URL: https://issues.apache.org/jira/browse/IGNITE-8514
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.5
>
>
> The packages below have no descriptions in javadoc:
> /doc/javadoc/overview-summary.html
> {noformat}
> org.apache.ignite.spi.communication.tcp.internal
> org.apache.ignite.spi.discovery.zk
> org.apache.ignite.spi.discovery.zk.internal
> org.apache.ignite.ml.structures.partition
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8514) Missed descriptions for a few packages in Javadoc

[Andrey Gura (JIRA)]

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

Andrey Gura reassigned IGNITE-8514:
---

Assignee: Andrey Gura

> Missed descriptions for a few packages in Javadoc
> -
>
> Key: IGNITE-8514
> URL: https://issues.apache.org/jira/browse/IGNITE-8514
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Sergey Kozlov
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.5
>
>
> The packages below have no descriptions in javadoc:
> /doc/javadoc/overview-summary.html
> {noformat}
> org.apache.ignite.spi.communication.tcp.internal
> org.apache.ignite.spi.discovery.zk
> org.apache.ignite.spi.discovery.zk.internal
> org.apache.ignite.ml.structures.partition
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8406:


GitHub user 1vanan opened a pull request:

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

IGNITE-8406



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

$ git pull https://github.com/1vanan/ignite IGNITE-8406

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

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


commit d87793b407fe0f559a15871586961e0b33071733
Author: Fedotov 
Date:   2018-05-08T09:21:05Z

change javaDoc in IgniteDataStreamer




> Update IgniteDataStreamer.flush() javadoc
> -
>
> Key: IGNITE-8406
> URL: https://issues.apache.org/jira/browse/IGNITE-8406
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Ivan Fedotov
>Priority: Minor
> Fix For: 2.6
>
>
> Current {{flush()}} implementation can throw {{CacheException}} if one or 
> more futures previously returned by {{addData()}} have been completed 
> exceptionally. This behavior should be described in {{IgniteDataStreamer}} 
> javadoc. Also it's worth noting explicitly that all futures completion upon 
> return from {{flush}} does not imply all those future listeners have been 
> completed by this moment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7818) Incorrect assertion in PDS page eviction method

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov commented on IGNITE-7818:
--

[~alex_pl], [~SomeFire] thanks!

[~dpavlov], can you look at this PR, please?

> Incorrect assertion in PDS page eviction method
> ---
>
> Key: IGNITE-7818
> URL: https://issues.apache.org/jira/browse/IGNITE-7818
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Fedotov
>Priority: Major
>
> There is an assertion in the method 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.Segment#removePageForReplacement:
>  
> {code:java}
> assert relRmvAddr != INVALID_REL_PTR;{code}
> Which seems potentially dangerous. In some rare cases, when count of 
> interations more then 40% of allocated pages and all processed pages are 
> aquired, the {{relRmvAddr}} variable will be uninitialized and 
> {{AssertionException}} will be thrown. But it's a correct case and page to 
> evict can be found later in the method {{tryToFindSequentially.}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8544) WAL disabling during rebalance mechanism uses wrong topology version in case of exchanges merge

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8544:


Github user asfgit closed the pull request at:

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


> WAL disabling during rebalance mechanism uses wrong topology version in case 
> of exchanges merge
> ---
>
> Key: IGNITE-8544
> URL: https://issues.apache.org/jira/browse/IGNITE-8544
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.6
>
>
> After exchange is done, we're using initial exchange version to determine 
> topology version on what rebalance should be finished and save it. After 
> rebalance finishing we check current topology version and saved version and 
> if they are equal, we enable WAL, own partitions and do checkpoint. In other 
> case we do nothing, because of topology change. 
> In case of exchanges merge we're saving old topology version (before merge) 
> and it leads to ignoring logic of enabling WAL and etc, because check on 
> topology version will be always false-negative.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8544) WAL disabling during rebalance mechanism uses wrong topology version in case of exchanges merge

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8544:
--

Looks good, merged to master.

> WAL disabling during rebalance mechanism uses wrong topology version in case 
> of exchanges merge
> ---
>
> Key: IGNITE-8544
> URL: https://issues.apache.org/jira/browse/IGNITE-8544
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.6
>
>
> After exchange is done, we're using initial exchange version to determine 
> topology version on what rebalance should be finished and save it. After 
> rebalance finishing we check current topology version and saved version and 
> if they are equal, we enable WAL, own partitions and do checkpoint. In other 
> case we do nothing, because of topology change. 
> In case of exchanges merge we're saving old topology version (before merge) 
> and it leads to ignoring logic of enabling WAL and etc, because check on 
> topology version will be always false-negative.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration

[vk (JIRA)]

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

vk commented on IGNITE-5789:


Hi [~dpavlov], I resolved conflicts. Please take a look

> After client reconnects to server if server was restarted, client doesn't 
> create caches defined in client's configuration
> -
>
> Key: IGNITE-5789
> URL: https://issues.apache.org/jira/browse/IGNITE-5789
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Evgenii Zhuravlev
>Assignee: vk
>Priority: Major
> Fix For: 2.6
>
> Attachments: ClientReconnectAfterClusterRestartTest.java
>
>
> User with this problem on SO:
> https://stackoverflow.com/questions/46053089/ignite-cache-reconnection-issue-cache-is-stopped



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7951) Add metrics for remains to evict keys/partitions

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov updated IGNITE-7951:
--
Labels: jmx  (was: )

> Add metrics for remains to evict keys/partitions
> 
>
> Key: IGNITE-7951
> URL: https://issues.apache.org/jira/browse/IGNITE-7951
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: jmx
> Fix For: 2.6
>
>
> Need to add some metrics for remains to evict keys/partitions to indicate 
> total amount of evicting work. In some cases we have synchronous eviction and 
> it's critically important to know how many keys need to be evicted before 
> exchange process end and cluster became working again. In some other cases we 
> just wanna know what happens in cluster now (background eviction without 
> workload) and when cluster will became 100% healthy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7951) Add metrics for remains to evict keys/partitions

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov updated IGNITE-7951:
--
Fix Version/s: 2.6

> Add metrics for remains to evict keys/partitions
> 
>
> Key: IGNITE-7951
> URL: https://issues.apache.org/jira/browse/IGNITE-7951
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: jmx
> Fix For: 2.6
>
>
> Need to add some metrics for remains to evict keys/partitions to indicate 
> total amount of evicting work. In some cases we have synchronous eviction and 
> it's critically important to know how many keys need to be evicted before 
> exchange process end and cluster became working again. In some other cases we 
> just wanna know what happens in cluster now (background eviction without 
> workload) and when cluster will became 100% healthy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7951) Add metrics for remains to evict keys/partitions

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov commented on IGNITE-7951:
---

I want to clarify: this ticket is about keys left to evict in RENTING 
partitions after rebalance complete, and RENTING partitions count. It's not 
related in any way to page eviction, so I removed the link to ticket about page 
eviction rate to avoid confusion.

> Add metrics for remains to evict keys/partitions
> 
>
> Key: IGNITE-7951
> URL: https://issues.apache.org/jira/browse/IGNITE-7951
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Need to add some metrics for remains to evict keys/partitions to indicate 
> total amount of evicting work. In some cases we have synchronous eviction and 
> it's critically important to know how many keys need to be evicted before 
> exchange process end and cluster became working again. In some other cases we 
> just wanna know what happens in cluster now (background eviction without 
> workload) and when cluster will became 100% healthy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7818) Incorrect assertion in PDS page eviction method

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov commented on IGNITE-7818:
---

[~ivanan.fed] LGTM

> Incorrect assertion in PDS page eviction method
> ---
>
> Key: IGNITE-7818
> URL: https://issues.apache.org/jira/browse/IGNITE-7818
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Fedotov
>Priority: Major
>
> There is an assertion in the method 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.Segment#removePageForReplacement:
>  
> {code:java}
> assert relRmvAddr != INVALID_REL_PTR;{code}
> Which seems potentially dangerous. In some rare cases, when count of 
> interations more then 40% of allocated pages and all processed pages are 
> aquired, the {{relRmvAddr}} variable will be uninitialized and 
> {{AssertionException}} will be thrown. But it's a correct case and page to 
> evict can be found later in the method {{tryToFindSequentially.}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6075) CacheLoadingConcurrentGridStartSelfTest sometimes fails

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov commented on IGNITE-6075:
--

[~dpavlov], thanks!

> CacheLoadingConcurrentGridStartSelfTest sometimes fails
> ---
>
> Key: IGNITE-6075
> URL: https://issues.apache.org/jira/browse/IGNITE-6075
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Seems that not all keys are in a cache after loading via DataStreamer
> {{CacheLoadingConcurrentGridStartSelfTest.testLoadCacheWithDataStreamerSequential}}
> {noformat}
> [2017-08-15 13:25:38,435][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 30'th entry.
> [2017-08-15 13:25:39,277][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 40'th entry.
> [2017-08-15 13:25:40,100][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 50'th entry.
> [2017-08-15 13:25:40,866][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 60'th entry.
> [2017-08-15 13:25:41,666][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 70'th entry.
> [2017-08-15 13:25:42,453][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 80'th entry.
> [2017-08-15 13:25:43,211][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 90'th entry.
> [2017-08-15 13:25:43,944][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Data loaded.
> [2017-08-15 13:26:06,518][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Actual cache size: 98
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:8fe76132-b563-4b7e-b611-386f5de4 primary=true 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:b774fe8f-849a-4b1f-abf6-26acd5f2 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:d4f4a4ae-a1e3-4c6b-90b8-823898c3 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:17a2d999-045e-4e58-8be6-55930a30 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:e18c8fb1-c972-4a75-901c-818bbf91 primary=false 
> backup=true local peek=null
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov commented on IGNITE-8085:
--

In addition I noticed another problem in tests: during afterTest execution 
assert on leftLatch.await [1] can fails and G.stop(true) doesn't happen. 

I think we should wrap it into try{} finally{} and place G.stop(true) and reset 
of counters and latches in finally block.

[~dpavlov], what do you think?

[1][https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java#L179]

 

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-8547:
-

There's at least two approaches. Both involve fixing 
OptimizedObjectOutputStream.write0.

Approach 1:
{code}
if (obj instanceof Throwable && !(obj instanceof Externalizable) || 
BinaryUtils.isEnum(obj.getClass())) {
   writeByte(JDK);
   // Just let the JDK serialize our enum.
{code}

Approach 2:
{code}
Class cls;

if (obj instanceof Object[])
cls = Object[].class;
else if (BinaryUtils.isEnum(obj.getClass()))
cls = ((Enum)obj).getDeclaringClass();
else
cls = obj.getClass();

OptimizedClassDescriptor desc = classDescriptor(clsMap, cls, 
ctx, mapper);
{code}

Use declaring class for enum, hope that it gets interpreted correctly on the 
other side (looks like it does)

[~vkulichenko] I would love to hear your input on this one.

> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException, 
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
>   for (int i = 0; i < 16; i++) {
>   final int ii = i;
>   Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
> thread.start();
> threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
>   thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And 
> that's exactly what OptimizedMarshaller does.
> See also the attached test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov commented on IGNITE-8085:
--

[~dpavlov], I think it's reasonable to create new ticket for this problem, 
because now we can see that problem in the implementation, not in tests.

Now I see two reasons of this failure: problems with shell execution and log 
can be absent. [~ein], can there be a problem here with third-party library 
jsch?

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-8547:
-

This problem is also present in master.

> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException, 
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
>   for (int i = 0; i < 16; i++) {
>   final int ii = i;
>   Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
> thread.start();
> threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
>   thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And 
> that's exactly what OptimizedMarshaller does.
> See also the attached test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8547:


GitHub user alamar opened a pull request:

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

IGNITE-8547 Use JVM serialization for enum values with OptimizedMarshaller

.., avoid deadlock.

Also IGNITE-5087 Enum comparison fails after marshal-unmarshal with 
BinaryMarshaller.

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

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

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

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


commit beb2409cfe2045789443d47de735d879961d371e
Author: Andrey V. Mashenkov 
Date:   2017-06-23T09:26:06Z

GG-12352: Forcible node drop makes cluster instable in some cases.
Disable forcible node drop by default.

commit 802f18fc250cbae8959192c78bb28dc525ed3cf7
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Fix compilation

commit 39d2dec85a3c571dfdb1cd6189b53ae2413a5d22
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:41:30Z

Merge branch 'ignite-1.7.12-b2' into ignite-1.8.8

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/GridTopic.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoMessageFactory.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/IgniteIoTestMessage.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAdapter.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridDhtAtomicCache.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/task/GridTaskThreadContextKey.java
#   
modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite5.java

commit 96445156143b46b664f785b353463dd435ac342d
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:42:44Z

Merge remote-tracking branch 'origin/ignite-1.8.8' into ignite-1.8.8

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite5.java

commit 7c569f15a80ab9301c21011d2c9159e311e46cef
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:48:10Z

Merge remote-tracking branch 'origin/ignite-1.8.7.p1' into ignite-1.8.8

commit a64339449be8fa602cab3f2868c5f74004a7b747
Author: Igor Sapego 
Date:   2017-06-23T13:57:49Z

IGNITE-4370: Implemented writing of batch of parameters for ODBC.

(cherry picked from commit c10be5780589cc84e7929e234e4411d515166e0b)
(cherry picked from commit d268b32cb252a5f06887d2b803d27ddc20ded95f)

commit cbe5df51c423568782e31245c7f1aa06c9ba3be1
Author: Igor Sapego 
Date:   2017-06-13T16:47:00Z

IGNITE-5478: ODBC: SQLNumParams now returns number of required parameters.

(cherry picked from commit b1c56a1)

(cherry picked from commit 4a8f295)

commit 9ad513e68b89e907f7db36a3f3f0daca0e5986e6
Author: Igor Sapego 
Date:   2017-06-23T14:06:40Z

IGNITE-5478: Fix for cherry pick

(cherry picked from commit a2a4ec1ee9794cb542f146a07c6c67002cad444e)

commit bfec212b1ece0e9e791de6dfb642324834fa77ca
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit 1abc14fdc4e39d8245c3e50fb2cf3d183df08021
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit cb95f7aa729fda19b4c3b7a5ada903a1e1bc2eab
Author: Andrey V. Mashenkov 
Date:   2017-06-23T16:08:00Z

Merge remote-tracking branch 'origin/ignite-1.7.12' into ignite-1.7.12

commit f59007f2c1221d8dd22abb0a9692b4abb31e87ad
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit 2c7d3c03cd36aee4f0985e674f550a62fc64d2db
Author: Andrey V. Mashenkov 
Date:   2017-06-23T17:11:00Z

Merge branch 'ignite-1.8.8' into ignite-1.9.4

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePreloaderAdapter.java
#   

[jira] [Created] (IGNITE-8548) Make Apache Ignite JCache 1.1 specification compliant

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8548:
---

 Summary: Make Apache Ignite JCache 1.1 specification compliant
 Key: IGNITE-8548
 URL: https://issues.apache.org/jira/browse/IGNITE-8548
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
 Fix For: 2.6


JCache specification's license was changed to Apache 2.0, and 1.1 version was 
released:
https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU

Ignite needs to:
* Upgrade to JCacahe 1.1 in general to use Apache 2.0 license
*  Become JCache 1.1 compliant implementing new interfaces and passing TCK




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8548) Make Apache Ignite JCache 1.1 specification compliant

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-8548:

Labels: newbie  (was: )

> Make Apache Ignite JCache 1.1 specification compliant
> -
>
> Key: IGNITE-8548
> URL: https://issues.apache.org/jira/browse/IGNITE-8548
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> JCache specification's license was changed to Apache 2.0, and 1.1 version was 
> released:
> https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
> Ignite needs to:
> * Upgrade to JCacahe 1.1 in general to use Apache 2.0 license
> *  Become JCache 1.1 compliant implementing new interfaces and passing TCK



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6010) ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper fails sometimes

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-6010:
---
Fix Version/s: 2.6

> ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper fails sometimes
> ---
>
> Key: IGNITE-6010
> URL: https://issues.apache.org/jira/browse/IGNITE-6010
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper(ZookeeperIpFinderTest.java:365)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8182) ZookeeperDiscoverySpiTest#testRandomTopologyChanges_RestartZk fails on TC

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8182:
---
Component/s: zookeeper

> ZookeeperDiscoverySpiTest#testRandomTopologyChanges_RestartZk fails on TC
> -
>
> Key: IGNITE-8182
> URL: https://issues.apache.org/jira/browse/IGNITE-8182
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test fails on TC with the following stack trace in logs:
> {noformat}
> org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite, 
> zkConnectionString=127.0.0.1:45427,127.0.0.1:38620,127.0.0.1:45472, 
> joinTimeout=0, sesTimeout=3, clientReconnectDisabled=false, 
> internalLsnr=null]
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> Caused by: org.apache.ignite.spi.IgniteSpiException: Failed to initialize 
> Zookeeper nodes
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> Caused by: 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClientFailedException: 
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
> = ConnectionLoss for /apacheIgnite
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: 
> KeeperErrorCode = ConnectionLoss for /apacheIgnite
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> {noformat}
> Reproducible on TC, investigation of failure conditions is needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8180) ZookeeperDiscoverySpiTest#testQuorumRestore fails on TC

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8180:
---
Component/s: zookeeper

> ZookeeperDiscoverySpiTest#testQuorumRestore fails on TC
> ---
>
> Key: IGNITE-8180
> URL: https://issues.apache.org/jira/browse/IGNITE-8180
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test fails on TC with the following stack trace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:683)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testQuorumRestore(ZookeeperDiscoverySpiTest.java:1077)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite, 
> zkConnectionString=127.0.0.1:40921,127.0.0.1:35014,127.0.0.1:38754, 
> joinTimeout=0, sesTimeout=15000, clientReconnectDisabled=false, 
> internalLsnr=null]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 20 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to 
> initialize Zookeeper nodes
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:827)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoin(ZookeeperDiscoveryImpl.java:957)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:775)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:693)
> at 
> org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:471)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> ... 22 more
> Caused by: 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClientFailedException: 
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
> = ConnectionLoss for /apacheIgnite
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.onZookeeperError(ZookeeperClient.java:758)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.exists(ZookeeperClient.java:276)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:789)
> ... 27 more
> Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: 
> KeeperErrorCode = ConnectionLoss for 

[jira] [Updated] (IGNITE-8183) ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8183:
---
Component/s: zookeeper

> ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
> ---
>
> Key: IGNITE-8183
> URL: https://issues.apache.org/jira/browse/IGNITE-8183
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test fails with assertion on awaits on latch:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testSegmentation3(ZookeeperDiscoverySpiTest.java:1060)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason SEGMENTATION event is never fired, so assertion on latch 
> fails. Investigation is needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8110) GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from milliseconds to nanoseconds.

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8110:

Fix Version/s: (was: 2.6)

> GridCacheWriteBehindStore.Flusher thread uses the wrong transformation from 
> milliseconds to nanoseconds.
> 
>
> Key: IGNITE-8110
> URL: https://issues.apache.org/jira/browse/IGNITE-8110
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Anton Kurbanov
>Priority: Minor
> Fix For: 2.5
>
>
> The initial value of a cache flushing frequency is defined as follows:
> {code}
> /** Cache flushing frequence in nanos. */
> protected long cacheFlushFreqNanos = cacheFlushFreq * 1000;
> {code}
> where is {{cacheFlushFreq}} is equal to
> {code}
> /** Default flush frequency for write-behind cache store in milliseconds. 
> */
> public static final long DFLT_WRITE_BEHIND_FLUSH_FREQUENCY = 5000;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-8547:
-

It seems that, for Binary Marshaller, this behavior were fixed by IGNITE-5087.

> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException, 
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
>   for (int i = 0; i < 16; i++) {
>   final int ii = i;
>   Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
> thread.start();
> threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
>   thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And 
> that's exactly what OptimizedMarshaller does.
> See also the attached test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8547:

Description: 
Due to the following problem:
{code}
package jvmtest;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class LegTypeTest {
public static void main(String[] args) throws InterruptedException, 
BrokenBarrierException {
List threadList = new ArrayList<>();

CyclicBarrier b1 = new CyclicBarrier(16);
CyclicBarrier b2 = new CyclicBarrier(17);

for (int i = 0; i < 16; i++) {
final int ii = i;
Thread thread = new Thread(() -> {
try {
b1.await();

if (ii % 2 == 0)
Class.forName("jvmtest.LegTypeTest$E$1");

if (ii % 2 == 1)
Class.forName("jvmtest.LegTypeTest$E");

b2.await();
} catch (Exception e) {
e.printStackTrace();
}
});
thread.start();
threadList.add(thread);
}

b2.await();

for (Thread thread : threadList) {
thread.join();
}
}

private enum E {
A("A"),
B("B") {
@Override
public String virtual() {
return null;
}
};

private String displayString;

E(String displayString) {
this.displayString = displayString;
}

public String virtual() {
return displayString;
}
}
}
{code}
When doing Class.forName on different enum values deadlock can be caused. And 
that's exactly what OptimizedMarshaller does.

See also the attached test.

  was:
Due to the following problem:
{code}
package jvmtest;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class LegTypeTest {
public static void main(String[] args) throws InterruptedException, 
BrokenBarrierException {
List threadList = new ArrayList<>();

CyclicBarrier b1 = new CyclicBarrier(16);
CyclicBarrier b2 = new CyclicBarrier(17);

for (int i = 0; i < 16; i++) {
final int ii = i;
Thread thread = new Thread(() -> {
try {
b1.await();

if (ii % 2 == 0)
Class.forName("jvmtest.LegTypeTest$E$1");

if (ii % 2 == 1)
Class.forName("jvmtest.LegTypeTest$E");

b2.await();
} catch (Exception e) {
e.printStackTrace();
}
});
thread.start();
threadList.add(thread);
}

b2.await();

for (Thread thread : threadList) {
thread.join();
}
}

private enum E {
A("A"),
B("B") {
@Override
public String virtual() {
return null;
}
};

private String displayString;

E(String displayString) {
this.displayString = displayString;
}

public String virtual() {
return displayString;
}
}
}
{code}
When doing Class.forName on different enum values deadlock can be caused. And 
that's exactly what OptimizedMarshaller does.

See also the attached test.


> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException, 
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
>   for (int i = 0; i < 16; i++) {
>   final int ii = i;
>   Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> 

[jira] [Commented] (IGNITE-8524) Document consistency check utilities

[Alexander Gerus (JIRA)]

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

Alexander Gerus commented on IGNITE-8524:
-

[~ivan.glukos], Hi Ivan, do you have any forecasted date for the task to be 
completed? Our client is waiting for this spec.

Many thanks

> Document consistency check utilities
> 
>
> Key: IGNITE-8524
> URL: https://issues.apache.org/jira/browse/IGNITE-8524
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.5
>
>
> Ignite 2.5 will go with special consistency check utilities that, for 
> instance, ensure that the data stays consistent across backups, indexes are 
> correct and many other things. More details can be taken from here:
> * https://issues.apache.org/jira/browse/IGNITE-8277
> * https://issues.apache.org/jira/browse/IGNITE-7467
> Here is an empty page that is created for the documentation: 
> https://apacheignite.readme.io/docs/consistency-check-utilities



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8547:

Description: 
Due to the following problem:
{code}
package jvmtest;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class LegTypeTest {
public static void main(String[] args) throws InterruptedException, 
BrokenBarrierException {
List threadList = new ArrayList<>();

CyclicBarrier b1 = new CyclicBarrier(16);
CyclicBarrier b2 = new CyclicBarrier(17);

for (int i = 0; i < 16; i++) {
final int ii = i;
Thread thread = new Thread(() -> {
try {
b1.await();

if (ii % 2 == 0)
Class.forName("jvmtest.LegTypeTest$E$1");

if (ii % 2 == 1)
Class.forName("jvmtest.LegTypeTest$E");

b2.await();
} catch (Exception e) {
e.printStackTrace();
}
});
thread.start();
threadList.add(thread);
}

b2.await();

for (Thread thread : threadList) {
thread.join();
}
}

private enum E {
A("A"),
B("B") {
@Override
public String virtual() {
return null;
}
};

private String displayString;

E(String displayString) {
this.displayString = displayString;
}

public String virtual() {
return displayString;
}
}
}
{code}
When doing Class.forName on different enum values deadlock can be caused. And 
that's exactly what OptimizedMarshaller does.

See also the attached test.

  was:
Due to the following problem:
{code}
package jvmtest;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class LegTypeTest {
public static void main(String[] args) throws InterruptedException, 
BrokenBarrierException {
List threadList = new ArrayList<>();

CyclicBarrier b1 = new CyclicBarrier(16);
CyclicBarrier b2 = new CyclicBarrier(17);

for (int i = 0; i < 16; i++) {
final int ii = i;
Thread thread = new Thread(() -> {
try {
b1.await();

if (ii % 2 == 0)
Class.forName("jvmtest.LegTypeTest$E$1");

if (ii % 2 == 1)
Class.forName("jvmtest.LegTypeTest$E");

b2.await();
} catch (Exception e) {
e.printStackTrace();
}
});
thread.start();
threadList.add(thread);
}

b2.await();

for (Thread thread : threadList) {
thread.join();
}
}

private enum E {
A("A"),
B("B") {
@Override
public String virtual() {
return null;
}
};

private String displayString;

E(String displayString) {
this.displayString = displayString;
}

public String virtual() {
return displayString;
}
}
}
{code}
When doing Class.forName on different enum values deadlock can be caused. And 
that's exactly what OptimizedMarshaller does.

See also the attached test.


> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException, 
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
>   for (int i = 0; i < 16; i++) {
>   final int ii = i;
>   Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
>  

[jira] [Updated] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8547:

Attachment: MarshallerDeadlockMultiJvmTest.java

> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
>   public static void main(String[] args) throws InterruptedException, 
> BrokenBarrierException {
>   List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
>   for (int i = 0; i < 16; i++) {
>   final int ii = i;
>   Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
>   thread.start();
>   threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
>   thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And 
> that's exactly what OptimizedMarshaller does.
> See also the attached test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8547:
---

 Summary: Deserialization of Enum values as anonymous classes may 
cause deadlock
 Key: IGNITE-8547
 URL: https://issues.apache.org/jira/browse/IGNITE-8547
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Ilya Kasnacheev


Due to the following problem:
{code}
package jvmtest;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class LegTypeTest {
public static void main(String[] args) throws InterruptedException, 
BrokenBarrierException {
List threadList = new ArrayList<>();

CyclicBarrier b1 = new CyclicBarrier(16);
CyclicBarrier b2 = new CyclicBarrier(17);

for (int i = 0; i < 16; i++) {
final int ii = i;
Thread thread = new Thread(() -> {
try {
b1.await();

if (ii % 2 == 0)
Class.forName("jvmtest.LegTypeTest$E$1");

if (ii % 2 == 1)
Class.forName("jvmtest.LegTypeTest$E");

b2.await();
} catch (Exception e) {
e.printStackTrace();
}
});
thread.start();
threadList.add(thread);
}

b2.await();

for (Thread thread : threadList) {
thread.join();
}
}

private enum E {
A("A"),
B("B") {
@Override
public String virtual() {
return null;
}
};

private String displayString;

E(String displayString) {
this.displayString = displayString;
}

public String virtual() {
return displayString;
}
}
}
{code}
When doing Class.forName on different enum values deadlock can be caused. And 
that's exactly what OptimizedMarshaller does.

See also the attached test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev reassigned IGNITE-8547:
---

Assignee: Ilya Kasnacheev

> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
>   public static void main(String[] args) throws InterruptedException, 
> BrokenBarrierException {
>   List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
>   for (int i = 0; i < 16; i++) {
>   final int ii = i;
>   Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
>   thread.start();
>   threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
>   thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And 
> that's exactly what OptimizedMarshaller does.
> See also the attached test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov edited comment on IGNITE-8238 at 5/21/18 4:22 PM:
--

[~amashenkov]

I'm sorry but I don't understand the question.

If you are asking why I didn't do it, the answer is: there isn't anything about 
such approach in issue description or in your comments.

In the previous comment you have written:
{quote}<...>

This behavior isn't mentioned in javadoc.

<...>

I think we shouldn't use RuntimeException class directly, but throws smth 
meaningful either IgniteException or IllegalStateException.
{quote}
So I have chosen IllegalStateException and added information in Javadoc. That's 
it.

 

If you want I can rework PR with the new approach. But please specify for me 
some details:
 # Do you want to throw NodeStoppingException (which is checked) wrapped into 
IgniteException from #checkpointReadLock()*?*
 # Do you interesting only an exception from GridCacheUtils#unwindEvicts *?* I 
mean checkpointReadLock are called in 81 places in the project, so there is no 
pipeline as checkpointReadLock -> unwindEvicts.
 # Do you want to catch IgniteException with NodeStoppingException cause in 
GridCacheTtlManager#expire (GridCacheUtils#unwindEvicts call it)*?* Now it 
catches only IgniteCheckedException.
 # When you are writing "Ignored" do you mean "logged"*?* Now 
GridCacheTtlManager#expire is logging exception with error level – is this a 
fine behaver?

Maybe my questions look as over-detailed, but I don't want to misunderstand you 
twice in one PR:)


was (Author: sharpler):
[~amashenkov]

I'm sorry but I don't understand the question.

If you are asking why I didn't do it, the answer is: there isn't anything about 
such approach in issue description or in your comments.

In the previous comment you have written:
{quote}<...>

This behavior isn't mentioned in javadoc.

<...>

I think we shouldn't use RuntimeException class directly, but throws smth 
meaningful either IgniteException or IllegalStateException. 
{quote}
So I have chosen IllegalStateException and added information in Javadoc. That's 
it.

 

If you want I can rework PR with the new approach. But please specify for me 
some details:
 # Do you want to throw NodeStopp*ing*Exception (which is checked) wrapped into 
IgniteException from #checkpointReadLock()*?*
 # Do you interesting only an exception from GridCacheUtils#unwindEvicts*?* I 
mean checkpointReadLock are called in 81 places in the project, so there is no 
pipeline as checkpointReadLock -> unwindEvicts.
 # Do you want to catch IgniteException with NodeStoppingException cause in 
GridCacheTtlManager#expire (GridCacheUtils#unwindEvicts call it)*?* Now it 
catches only IgniteCheckedException.
 # When you are writing "Ignored" do you mean "logged"*?* Now 
GridCacheTtlManager#expire is logging exception with error level – is this a 
fine behaver?

Maybe my questions look as over-detailed, but I don't want to misunderstand you 
twice in one PR:)

> Operation can fails with unexpected RuntimeException when node is stopping.
> ---
>
> Key: IGNITE-8238
> URL: https://issues.apache.org/jira/browse/IGNITE-8238
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
>Priority: Minor
> Fix For: 2.6
>
>
> Operation can fails with RuntimeException when node is stoped in other 
> thread. 
> It is not clear from javadoc that operation can throws RuntimeException.
>  We should add it to javadoc or e.g. throws IllegalStateException which 
> already present in java cache api javadoc.
> Failure in thread: Thread [id=3484, name=updater-2]
> java.lang.RuntimeException: Failed to perform cache update: node is stopping.
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>  at 
> 

[jira] [Updated] (IGNITE-8183) ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8183:
---
Labels: MakeTeamcityGreenAgain  (was: )

> ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
> ---
>
> Key: IGNITE-8183
> URL: https://issues.apache.org/jira/browse/IGNITE-8183
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test fails with assertion on awaits on latch:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testSegmentation3(ZookeeperDiscoverySpiTest.java:1060)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason SEGMENTATION event is never fired, so assertion on latch 
> fails. Investigation is needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8184) ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk* tests fail on TC

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8184:
---
Labels: MakeTeamcityGreenAgain  (was: )

> ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk* tests 
> fail on TC
> -
>
> Key: IGNITE-8184
> URL: https://issues.apache.org/jira/browse/IGNITE-8184
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Tests fail on TC but pass locally.
> There are some errors in logs like this:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$3.call(GridAbstractTest.java:742)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite, 
> zkConnectionString=127.0.0.1:45822,127.0.0.1:46661,127.0.0.1:43724, 
> joinTimeout=0, sesTimeout=3, clientReconnectDisabled=false, 
> internalLsnr=null]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 11 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to 
> initialize Zookeeper nodes
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:827)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoin(ZookeeperDiscoveryImpl.java:957)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:775)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:693)
> at 
> org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:471)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> ... 13 more
> Caused by: 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClientFailedException: 
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
> = ConnectionLoss for /apacheIgnite
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.onZookeeperError(ZookeeperClient.java:808)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.exists(ZookeeperClient.java:276)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:789)
> ... 18 more
> Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: 
> KeeperErrorCode = ConnectionLoss for /apacheIgnite
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1045)
> at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1073)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.exists(ZookeeperClient.java:273)
> ... 19 more
> {noformat}
> Also there is some signs that test may hang:
> {noformat}
> org.apache.ignite.IgniteException: Timeout of waiting for topology map update 
> [igniteInstanceName=internal.ZookeeperDiscoverySpiTest3, cache=default, 
> cacheId=1544803905, 

[jira] [Updated] (IGNITE-8180) ZookeeperDiscoverySpiTest#testQuorumRestore fails on TC

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8180:
---
Labels: MakeTeamcityGreenAgain  (was: )

> ZookeeperDiscoverySpiTest#testQuorumRestore fails on TC
> ---
>
> Key: IGNITE-8180
> URL: https://issues.apache.org/jira/browse/IGNITE-8180
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test fails on TC with the following stack trace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:683)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testQuorumRestore(ZookeeperDiscoverySpiTest.java:1077)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite, 
> zkConnectionString=127.0.0.1:40921,127.0.0.1:35014,127.0.0.1:38754, 
> joinTimeout=0, sesTimeout=15000, clientReconnectDisabled=false, 
> internalLsnr=null]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 20 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to 
> initialize Zookeeper nodes
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:827)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoin(ZookeeperDiscoveryImpl.java:957)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:775)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:693)
> at 
> org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:471)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> ... 22 more
> Caused by: 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClientFailedException: 
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
> = ConnectionLoss for /apacheIgnite
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.onZookeeperError(ZookeeperClient.java:758)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.exists(ZookeeperClient.java:276)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:789)
> ... 27 more
> Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: 
> KeeperErrorCode = ConnectionLoss for /apacheIgnite
> at 

[jira] [Updated] (IGNITE-8179) ZookeeperDiscoverySpiTest#testCommunicationFailureResolve_KillRandom always fails on TC

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8179:
---
Labels: MakeTeamcityGreenAgain  (was: )

> ZookeeperDiscoverySpiTest#testCommunicationFailureResolve_KillRandom always 
> fails on TC
> ---
>
> Key: IGNITE-8179
> URL: https://issues.apache.org/jira/browse/IGNITE-8179
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test fails on TC with the following stack trace:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:683)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGridsMultiThreaded(GridAbstractTest.java:710)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.startGridsMultiThreaded(GridCommonAbstractTest.java:507)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.startGridsMultiThreaded(GridCommonAbstractTest.java:497)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_KillRandom(ZookeeperDiscoverySpiTest.java:2742)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite, 
> zkConnectionString=127.0.0.1:40921,127.0.0.1:35014,127.0.0.1:38754, 
> joinTimeout=0, sesTimeout=2000, clientReconnectDisabled=false, 
> internalLsnr=null]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 23 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to 
> initialize Zookeeper nodes
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:827)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoin(ZookeeperDiscoveryImpl.java:957)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:775)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:693)
> at 
> org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:471)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> ... 25 more
> Caused by: 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClientFailedException: 
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode 
> = Session expired for 

[jira] [Updated] (IGNITE-8182) ZookeeperDiscoverySpiTest#testRandomTopologyChanges_RestartZk fails on TC

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8182:
---
Labels: MakeTeamcityGreenAgain  (was: )

> ZookeeperDiscoverySpiTest#testRandomTopologyChanges_RestartZk fails on TC
> -
>
> Key: IGNITE-8182
> URL: https://issues.apache.org/jira/browse/IGNITE-8182
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test fails on TC with the following stack trace in logs:
> {noformat}
> org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
> ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite, 
> zkConnectionString=127.0.0.1:45427,127.0.0.1:38620,127.0.0.1:45472, 
> joinTimeout=0, sesTimeout=3, clientReconnectDisabled=false, 
> internalLsnr=null]
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> Caused by: org.apache.ignite.spi.IgniteSpiException: Failed to initialize 
> Zookeeper nodes
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> Caused by: 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperClientFailedException: 
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
> = ConnectionLoss for /apacheIgnite
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: 
> KeeperErrorCode = ConnectionLoss for /apacheIgnite
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.randomTopologyChanges(ZookeeperDiscoverySpiTest.java:3791)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testRandomTopologyChanges_RestartZk(ZookeeperDiscoverySpiTest.java:2035)
> {noformat}
> Reproducible on TC, investigation of failure conditions is needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-8131:
---
Labels: MakeTeamcityGreenAgain  (was: )

> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
> 
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect 
> event.
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't 
> generate these events as it supposed to do.
> (TC runs can be found 
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low 
> probability: one failure for 50 or even 300 successful executions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8463) Node.js: setup TeamCity

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-8463:
--

Integrated TLS: https://ci.ignite.apache.org/viewLog.html?buildId=1318038. 
Please check that TLS test problem is test failure, not build.

> Node.js: setup TeamCity
> ---
>
> Key: IGNITE-8463
> URL: https://issues.apache.org/jira/browse/IGNITE-8463
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
>
> Minimal implementation of NodeJS client is almost ready (IGNITE-8014). We 
> need to figure out how to integrate it with TeamCity:
> 1) New suite for NodeJS is needed along with required environment (npm, any 
> recent version). 2) Suite should be able to run Jasmine tests [1]
> 3) Currently all tests rely on manually started external node. We need to 
> create a set of scripts (bash?) to start/stop nodes locally from Jasmine. Raw 
> suggestion: call {{ignite.sh}} with predefined configuration.
> [1] https://jasmine.github.io/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8546) Permission denied while copying OPTION_LIBS on Openshift

[Roman Guseinov (JIRA)]

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

Roman Guseinov updated IGNITE-8546:
---
Attachment: (was: Dockerfile)

> Permission denied while copying OPTION_LIBS on Openshift
> 
>
> Key: IGNITE-8546
> URL: https://issues.apache.org/jira/browse/IGNITE-8546
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.4
> Environment: Server https://api.pro-us-east-1.openshift.com:443
> openshift v3.9.14
> kubernetes v1.9.1+a0ce1bc657
>Reporter: Roman Guseinov
>Priority: Major
> Attachments: Dockerfile
>
>
> The issue happens when we try to deploy `apacheignite/ignite:2.4.0` on 
> Openshift with specified OPTION_LIBS env variable 
> "ignite-kubernetes,ignite-rest-http".
> There is a workaround how to resolve this issue. Dockerfile is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8546) Permission denied while copying OPTION_LIBS on Openshift

[Roman Guseinov (JIRA)]

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

Roman Guseinov updated IGNITE-8546:
---
Attachment: Dockerfile

> Permission denied while copying OPTION_LIBS on Openshift
> 
>
> Key: IGNITE-8546
> URL: https://issues.apache.org/jira/browse/IGNITE-8546
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.4
> Environment: Server https://api.pro-us-east-1.openshift.com:443
> openshift v3.9.14
> kubernetes v1.9.1+a0ce1bc657
>Reporter: Roman Guseinov
>Priority: Major
> Attachments: Dockerfile
>
>
> The issue happens when we try to deploy `apacheignite/ignite:2.4.0` on 
> Openshift with specified OPTION_LIBS env variable 
> "ignite-kubernetes,ignite-rest-http".
> There is a workaround how to resolve this issue. Dockerfile is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8546) Permission denied while copying OPTION_LIBS on Openshift

[Roman Guseinov (JIRA)]

Roman Guseinov created IGNITE-8546:
--

 Summary: Permission denied while copying OPTION_LIBS on Openshift
 Key: IGNITE-8546
 URL: https://issues.apache.org/jira/browse/IGNITE-8546
 Project: Ignite
  Issue Type: Bug
  Components: build
Affects Versions: 2.4
 Environment: Server https://api.pro-us-east-1.openshift.com:443
openshift v3.9.14
kubernetes v1.9.1+a0ce1bc657
Reporter: Roman Guseinov
 Attachments: Dockerfile

The issue happens when we try to deploy `apacheignite/ignite:2.4.0` on 
Openshift with specified OPTION_LIBS env variable 
"ignite-kubernetes,ignite-rest-http".

There is a workaround how to resolve this issue. Dockerfile is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8446) Ability to check and completely fill transactions on creation

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-8446 at 5/21/18 3:54 PM:
---

According to [~yzhdanov]'s comments at devlist issues should be implemented in 
different way.

New Idea proposed on devlist.


was (Author: avinogradov):
According to [~yzhdanov]'s comments at devlist issues should be implemented in 
different way.

> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.6
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7778) User's authentication data must be persisted on cluster with disabled persistence

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7778:
--

[~vozerov], please review the patch.

> User's authentication data must be persisted on cluster with disabled 
> persistence
> -
>
> Key: IGNITE-7778
> URL: https://issues.apache.org/jira/browse/IGNITE-7778
> Project: Ignite
>  Issue Type: Task
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The ticket is related to the: IGNITE-7436 (introduce users in Ignite)
> {{IgniteAuthenticationProcessor}} uses metastorage to persist user data. But 
> metastorage works only with persistent cluster. We have to support user 
> authentication for in-memory cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-1793:


[~v.pyatkov] what do you think? Would you like to take a look to this failure 
after enabling test?

> [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC 
> sometimes
> -
>
> Key: IGNITE-1793
> URL: https://issues.apache.org/jira/browse/IGNITE-1793
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Attachments: test.logs
>
>
> IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
> Test hangs on IgniteCountDownLatch.count() method.
> {noformat}
> Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
> Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154, 
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
> at 
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
> at 
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
> at 
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
> at 
> o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
> at 
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
> at 
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
> at 
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
> at 
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
> at 
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at 
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at 
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8545:

Attachment: IgniteSqlSplitterQueryParallelismTest.java

> If queryParallelism in nodes' caches configurations differ, query may hang, 
> assert or return incomplete results
> ---
>
> Key: IGNITE-8545
> URL: https://issues.apache.org/jira/browse/IGNITE-8545
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Attachments: IgniteSqlSplitterQueryParallelismTest.java
>
>
> I imagine it should not. See the attached file.
> It happens both with client nodes and with server nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev updated IGNITE-8545:

Attachment: (was: IgniteSqlSplitterQueryParallelismTest.java)

> If queryParallelism in nodes' caches configurations differ, query may hang, 
> assert or return incomplete results
> ---
>
> Key: IGNITE-8545
> URL: https://issues.apache.org/jira/browse/IGNITE-8545
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Priority: Critical
>
> I imagine it should not. See the attached file.
> It happens both with client nodes and with server nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8533) Timeout collision in Client Nodes test suite

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8533:


Github user asfgit closed the pull request at:

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


> Timeout collision in Client Nodes test suite
> 
>
> Key: IGNITE-8533
> URL: https://issues.apache.org/jira/browse/IGNITE-8533
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrew Medvedev
>Assignee: Andrew Medvedev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> IGNITE-8085 increased NODE_START_CHECK_LIMIT so "remote" node log is parsed 
> for longer (set now to 25 * 2000ms)
> https://github.com/apache/ignite/blob/fe6e70e3c8d6a6349ea00b7ec99b215945ffce6d/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L85
>  
> This exceeds total timeout set up for remote node startup in 
> [https://github.com/apache/ignite/blob/282b334f76479460613f28347d8cea97ba23f795/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java#L1054]
>  (40 * 1000ms)
>  
> This leads to debug message with ref to remote log file being never shown 
> because 5 timeout will never be reached
> [https://github.com/apache/ignite/blob/fe6e70e3c8d6a6349ea00b7ec99b215945ffce6d/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L285]
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8545:
---

 Summary: If queryParallelism in nodes' caches configurations 
differ, query may hang, assert or return incomplete results
 Key: IGNITE-8545
 URL: https://issues.apache.org/jira/browse/IGNITE-8545
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.6
Reporter: Ilya Kasnacheev
 Attachments: IgniteSqlSplitterQueryParallelismTest.java

I imagine it should not. See the attached file.

It happens both with client nodes and with server nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8544) WAL disabling during rebalance mechanism uses wrong topology version in case of exchanges merge

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8544:


GitHub user Jokser opened a pull request:

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

IGNITE-8544 Use exchange result topology version for local wal state change



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

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

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

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


commit 139a1fe580f777c081d073cca8199369de1878dd
Author: Pavel Kovalenko 
Date:   2018-05-21T15:01:21Z

IGNITE-8544 Use exchange result topology version for local wal state 
management.




> WAL disabling during rebalance mechanism uses wrong topology version in case 
> of exchanges merge
> ---
>
> Key: IGNITE-8544
> URL: https://issues.apache.org/jira/browse/IGNITE-8544
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.6
>
>
> After exchange is done, we're using initial exchange version to determine 
> topology version on what rebalance should be finished and save it. After 
> rebalance finishing we check current topology version and saved version and 
> if they are equal, we enable WAL, own partitions and do checkpoint. In other 
> case we do nothing, because of topology change. 
> In case of exchanges merge we're saving old topology version (before merge) 
> and it leads to ignoring logic of enabling WAL and etc, because check on 
> topology version will be always false-negative.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8533) Timeout collision in Client Nodes test suite

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-8533:
--

Assignee: Andrew Medvedev

> Timeout collision in Client Nodes test suite
> 
>
> Key: IGNITE-8533
> URL: https://issues.apache.org/jira/browse/IGNITE-8533
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrew Medvedev
>Assignee: Andrew Medvedev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> IGNITE-8085 increased NODE_START_CHECK_LIMIT so "remote" node log is parsed 
> for longer (set now to 25 * 2000ms)
> https://github.com/apache/ignite/blob/fe6e70e3c8d6a6349ea00b7ec99b215945ffce6d/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L85
>  
> This exceeds total timeout set up for remote node startup in 
> [https://github.com/apache/ignite/blob/282b334f76479460613f28347d8cea97ba23f795/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java#L1054]
>  (40 * 1000ms)
>  
> This leads to debug message with ref to remote log file being never shown 
> because 5 timeout will never be reached
> [https://github.com/apache/ignite/blob/fe6e70e3c8d6a6349ea00b7ec99b215945ffce6d/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L285]
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8544) WAL disabling during rebalance mechanism uses wrong topology version in case of exchanges merge

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-8544:

Description: 
After exchange is done, we're using initial exchange version to determine 
topology version on what rebalance should be finished and save it. After 
rebalance finishing we check current topology version and saved version and if 
they are equal, we enable WAL, own partitions and do checkpoint. In other case 
we do nothing, because of topology change. 
In case of exchanges merge we're saving old topology version (before merge) and 
it leads to ignoring logic of enabling WAL and etc, because check on topology 
version will be always false-negative.


  was:
After exchange is done, we're using initial exchange version to determine 
topology version on what rebalance should be finished and save it. After 
rebalance finishing we check current topology version and saved version and if 
they are equal, we enable WAL, own partitions and do checkpoint. In other case 
we do nothing, because of topology change. 
In case of exchanges merge we're saving old topology version (before merge) and 
it leads to ignoring logic of enabling WAL and etc, because check on topology 
version will be always false-positive.



> WAL disabling during rebalance mechanism uses wrong topology version in case 
> of exchanges merge
> ---
>
> Key: IGNITE-8544
> URL: https://issues.apache.org/jira/browse/IGNITE-8544
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.6
>
>
> After exchange is done, we're using initial exchange version to determine 
> topology version on what rebalance should be finished and save it. After 
> rebalance finishing we check current topology version and saved version and 
> if they are equal, we enable WAL, own partitions and do checkpoint. In other 
> case we do nothing, because of topology change. 
> In case of exchanges merge we're saving old topology version (before merge) 
> and it leads to ignoring logic of enabling WAL and etc, because check on 
> topology version will be always false-negative.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8544) WAL disabling during rebalance mechanism uses wrong topology version in case of exchanges merge

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8544:
---

 Summary: WAL disabling during rebalance mechanism uses wrong 
topology version in case of exchanges merge
 Key: IGNITE-8544
 URL: https://issues.apache.org/jira/browse/IGNITE-8544
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.6


After exchange is done, we're using initial exchange version to determine 
topology version on what rebalance should be finished and save it. After 
rebalance finishing we check current topology version and saved version and if 
they are equal, we enable WAL, own partitions and do checkpoint. In other case 
we do nothing, because of topology change. 
In case of exchanges merge we're saving old topology version (before merge) and 
it leads to ignoring logic of enabling WAL and etc, because check on topology 
version will be always false-positive.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8530) Exchange hangs during start/stop stress test

[Alexander Gerus (JIRA)]

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

Alexander Gerus commented on IGNITE-8530:
-

[~akalashnikov] Can you please help with analysis for the issue. It is really 
critical for multiple clients

> Exchange hangs during start/stop stress test
> 
>
> Key: IGNITE-8530
> URL: https://issues.apache.org/jira/browse/IGNITE-8530
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Mikhail Cherkasov
>Assignee: Anton Kalashnikov
>Priority: Major
> Attachments: LocalRunner.java, Main2.java
>
>
> Please see attached test, it starts N_CORES*2+2 nodes first and after this 
> starts N_CORES*2 threads with while(true) cycle in which closes and starts 
> nodes with small random pause.
> After couple minutes it hangs with Failed to wait for partition map exchange.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7951) Add metrics for remains to evict keys/partitions

[Aleksey Plekhanov (JIRA)]

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

Aleksey Plekhanov reassigned IGNITE-7951:
-

Assignee: Aleksey Plekhanov

> Add metrics for remains to evict keys/partitions
> 
>
> Key: IGNITE-7951
> URL: https://issues.apache.org/jira/browse/IGNITE-7951
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Need to add some metrics for remains to evict keys/partitions to indicate 
> total amount of evicting work. In some cases we have synchronous eviction and 
> it's critically important to know how many keys need to be evicted before 
> exchange process end and cluster became working again. In some other cases we 
> just wanna know what happens in cluster now (background eviction without 
> workload) and when cluster will became 100% healthy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6075) CacheLoadingConcurrentGridStartSelfTest sometimes fails

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6075:


[~ivanan.fed] I'll take a look

> CacheLoadingConcurrentGridStartSelfTest sometimes fails
> ---
>
> Key: IGNITE-6075
> URL: https://issues.apache.org/jira/browse/IGNITE-6075
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Seems that not all keys are in a cache after loading via DataStreamer
> {{CacheLoadingConcurrentGridStartSelfTest.testLoadCacheWithDataStreamerSequential}}
> {noformat}
> [2017-08-15 13:25:38,435][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 30'th entry.
> [2017-08-15 13:25:39,277][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 40'th entry.
> [2017-08-15 13:25:40,100][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 50'th entry.
> [2017-08-15 13:25:40,866][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 60'th entry.
> [2017-08-15 13:25:41,666][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 70'th entry.
> [2017-08-15 13:25:42,453][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 80'th entry.
> [2017-08-15 13:25:43,211][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 90'th entry.
> [2017-08-15 13:25:43,944][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Data loaded.
> [2017-08-15 13:26:06,518][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Actual cache size: 98
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:8fe76132-b563-4b7e-b611-386f5de4 primary=true 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:b774fe8f-849a-4b1f-abf6-26acd5f2 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:d4f4a4ae-a1e3-4c6b-90b8-823898c3 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:17a2d999-045e-4e58-8be6-55930a30 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:e18c8fb1-c972-4a75-901c-818bbf91 primary=false 
> backup=true local peek=null
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8266:


Github user asfgit closed the pull request at:

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


> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8469:


Github user asfgit closed the pull request at:

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


> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6075) CacheLoadingConcurrentGridStartSelfTest sometimes fails

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6075:
---
Fix Version/s: 2.6

> CacheLoadingConcurrentGridStartSelfTest sometimes fails
> ---
>
> Key: IGNITE-6075
> URL: https://issues.apache.org/jira/browse/IGNITE-6075
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Seems that not all keys are in a cache after loading via DataStreamer
> {{CacheLoadingConcurrentGridStartSelfTest.testLoadCacheWithDataStreamerSequential}}
> {noformat}
> [2017-08-15 13:25:38,435][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 30'th entry.
> [2017-08-15 13:25:39,277][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 40'th entry.
> [2017-08-15 13:25:40,100][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 50'th entry.
> [2017-08-15 13:25:40,866][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 60'th entry.
> [2017-08-15 13:25:41,666][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 70'th entry.
> [2017-08-15 13:25:42,453][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 80'th entry.
> [2017-08-15 13:25:43,211][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Streaming 90'th entry.
> [2017-08-15 13:25:43,944][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Data loaded.
> [2017-08-15 13:26:06,518][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Actual cache size: 98
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:8fe76132-b563-4b7e-b611-386f5de4 primary=true 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:b774fe8f-849a-4b1f-abf6-26acd5f2 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:d4f4a4ae-a1e3-4c6b-90b8-823898c3 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:17a2d999-045e-4e58-8be6-55930a30 primary=false 
> backup=false local peek=null
> [2017-08-15 13:26:06,519][INFO 
> ][test-runner-#54053%distributed.CacheLoadingConcurrentGridStartSelfTest%][root]
>  Missed key info:e18c8fb1-c972-4a75-901c-818bbf91 primary=false 
> backup=true local peek=null
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5945) Flaky failure in IgniteCache 5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate2

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-5945:
-

[~dpavlov]

I have fixed the issue.

The test was failing because of not finished rebalancing. So the following 
situation could have happened: we have got primary keys for a *srv0*, but after 
rebalancing primary keys move to *srv1*. And a blocking of 
*GridDhtAtomicNearResponse* message on *srv1* don't take effect.

So I just have added waitForRebalancing() *exactly in the same way* as it works 
in GridCacheRebalancingSyncSelfTest#testSimpleRebalancing().

You can see on TC 120 runs of this test with 3 other which is affected by my 
change, one of them was flaky too.
The last run on TC shows suite passing with final changes.

> Flaky failure in IgniteCache 5: 
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
> --
>
> Key: IGNITE-5945
> URL: https://issues.apache.org/jira/browse/IGNITE-5945
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest#testPutReaderUpdate2
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertFalse(Assert.java:39)
>   at junit.framework.Assert.assertFalse(Assert.java:47)
>   at junit.framework.TestCase.assertFalse(TestCase.java:219)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.readerUpdateDhtFails(IgniteCacheAtomicProtocolTest.java:865)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.testPutReaderUpdate2(IgniteCacheAtomicProtocolTest.java:765)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Fail is reproducable locally 2 times per 20 runs
> On TeamCity test success rate is 88,2%



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8469:
---
Summary: Non-heap memory leak for calling cluster activation multi times  
(was: Non-heap memroy leak for calling cluster activation multi times)

> Non-heap memory leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8526) Create web-agent docker image for k8s deployment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8526:


GitHub user vveider opened a pull request:

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

IGNITE-8526 Create web-agent docker image for k8s deployment

 * added web-agent separate docker image build
 * refactored and unified docker specifications layout

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

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

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

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


commit e6cc97a7592f1d5065e6f40dc0c96fc70018039f
Author: Ivanov Petr 
Date:   2018-05-21T14:11:05Z

IGNITE-8526 Create web-agent docker image for k8s deployment
 * added web-agent separate docker image build
 * refactored and unified docker specifications layout




> Create web-agent docker image for k8s deployment
> 
>
> Key: IGNITE-8526
> URL: https://issues.apache.org/jira/browse/IGNITE-8526
> Project: Ignite
>  Issue Type: Improvement
>  Components: build, UI
>Reporter: Roman Guseinov
>Assignee: Peter Ivanov
>Priority: Major
> Attachments: Dockerfile
>
>
> Currently, apacheignite/web-console-standalone is not enough to run 
> web-console in Kubernetes environment. The only way to connect a cluster from 
> web console is to use web-agent. That's why we need a docker image which we 
> can configure (grid and console addresses, security tokens) and run on k8s 
> env.
> Dockerfile example is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[Maxim Muzafarov (JIRA)]

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

Maxim Muzafarov commented on IGNITE-8266:
-

Last TC Run :: All

[#1759 (21 May 18 
10:32)|https://ci.ignite.apache.org/viewLog.html?buildId=1315970=buildResultsDiv=IgniteTests24Java8_RunAll]

> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8523) Java and Scala spark examples are mixed

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8523:

Fix Version/s: (was: 2.5)
   2.6

> Java and Scala spark examples are mixed
> ---
>
> Key: IGNITE-8523
> URL: https://issues.apache.org/jira/browse/IGNITE-8523
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Sergey Kozlov
>Priority: Blocker
> Fix For: 2.6
>
> Attachments: Снимок экрана от 2018-05-17 22-24-52.png
>
>
> Now {{ignite-example}} project has two locations to store spark examples:
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}} - single 
> spark example on Scala
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} - mix of java 
> and scala examples
> Moreover the profile {{scala}} activates spark folder but that folder has 
> Java examples as well. Thus I can't run java spark examples without {{scala}} 
> profile.
> The current implementation is weird and should be fixed by following way:
> 1. Make two locations where collect java and scala examples separately:
> {{examples/src/main/java/org/apache/ignite/examples/spark}} for java examples
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}} for scala 
> examples
> 2. Remove spark folder for {{scala}} profile



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-8266:
-

[~Mmuzaf], [~dpavlov] Looks good to me. I think these changes are ready to be 
merged.

> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8469) Non-heap memroy leak for calling cluster activation multi times

[Maxim Muzafarov (JIRA)]

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

Maxim Muzafarov commented on IGNITE-8469:
-

[~dpavlov]

I've added description comment and minor code style updates.

> Non-heap memroy leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7659) Reduce multiple Trainer interfaces to one

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-7659:


Done in parent ticket (IGNITE-8232), related PR is 
https://github.com/apache/ignite/pull/3806

> Reduce multiple Trainer interfaces to one
> -
>
> Key: IGNITE-7659
> URL: https://issues.apache.org/jira/browse/IGNITE-7659
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Minor
> Fix For: 2.5
>
>
> Currently there are two `Trainer` interfaces: in package 
> `org.apache.ignite.ml` and `org.apache.ignite.ml.trainers`. We need to use 
> only one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8469) Non-heap memroy leak for calling cluster activation multi times

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8469:


I've left several proposals in PR related to code style and formatting

> Non-heap memroy leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8436) Executor service for services does not shutdown properly

[Prabhat Ranjan (JIRA)]

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

Prabhat Ranjan commented on IGNITE-8436:


Thanks [~Mmuzaf],

I have created upsource branch review.
Also, I have updated my PR to accomodate your comments.

Please review.

> Executor service for services does not shutdown properly
> 
>
> Key: IGNITE-8436
> URL: https://issues.apache.org/jira/browse/IGNITE-8436
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Maxim Muzafarov
>Assignee: Prabhat Ranjan
>Priority: Major
>  Labels: newbie
> Fix For: 2.6
>
>
> Issue [IGNITE-4802|https://issues.apache.org/jira/browse/IGNITE-4802] 
> introduces us separete thread pool for services execution.
> {{IgniteEx}} class defines a factory for the main Ignite API. It controls 
> Grid life cycle and allows listening for grid events. 
> As cotributor, you should ensure that execution pool shutdowns properly and 
> provide fix if needed in case stop grid instance method call occurs.
> {code:java|title=IgniteEx.java|borderStyle=solid}
> /** Executor service for services. */
> private ThreadPoolExecutor svcExecSvc;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8534) Upgrade Ignite Spark Module's Spark version to 2.3.0

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-8534:
-

Hello, [~ldz]

I think you should raise a discussion on dev-list about your improvements
Do we really need to update spark to 2.3 right now?
Do we really need to remove 2.10 modules?

> Upgrade Ignite Spark Module's Spark version to 2.3.0
> 
>
> Key: IGNITE-8534
> URL: https://issues.apache.org/jira/browse/IGNITE-8534
> Project: Ignite
>  Issue Type: Improvement
>  Components: spark
>Reporter: Ray
>Assignee: Ray
>Priority: Major
> Fix For: 2.6
>
>
> Spark released its newest version 2.3.0 on Feb 28th, we should upgrade Ignite 
> Spark module to to the latest version.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8463) Node.js: setup TeamCity

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-8463:
--

[~ekaterina.vergizova], filed IGNITE-8543.

> Node.js: setup TeamCity
> ---
>
> Key: IGNITE-8463
> URL: https://issues.apache.org/jira/browse/IGNITE-8463
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
>
> Minimal implementation of NodeJS client is almost ready (IGNITE-8014). We 
> need to figure out how to integrate it with TeamCity:
> 1) New suite for NodeJS is needed along with required environment (npm, any 
> recent version). 2) Suite should be able to run Jasmine tests [1]
> 3) Currently all tests rely on manually started external node. We need to 
> create a set of scripts (bash?) to start/stop nodes locally from Jasmine. Raw 
> suggestion: call {{ignite.sh}} with predefined configuration.
> [1] https://jasmine.github.io/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8543) Node.js tests count with debug on/off differs

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8543:


 Summary: Node.js tests count with debug on/off differs
 Key: IGNITE-8543
 URL: https://issues.apache.org/jira/browse/IGNITE-8543
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Peter Ivanov
Assignee: Peter Ivanov


Running Node,js thin client tests with debug turned on / off results in 
different total test count 
([64|https://ci.ignite.apache.org/viewLog.html?buildId=1316067=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs]
 and 
[99|https://ci.ignite.apache.org/viewLog.html?buildId=1316268=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs]
 respectively. Thats not predicted behaviour and require investigation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-640) Implement IgniteMultimap data structures

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin edited comment on IGNITE-640 at 5/21/18 12:41 PM:
---

Hi [~aakhmedov], [~avinogradov].

In GridCacheMultimapImpl I noticed some things that you should pay attention to.

- Iterator of collocated multimap can be slow, because it performs full scan of 
shared cache, which may contain another multimap/queue/set instances. 
{{IgniteQueue}} avoids full cache scan by using elements indexing (see 
{{IgniteCacheQueueAdapter#itemKey}}), {{IgniteSet}} maintains plain Java sets 
(see {{CacheDataStructuresManager#setData}}). May be this behavior should be 
documented or discussed.
- Also I noticed a few calls
{code:java}cctx.kernalContext().cache().internalCache(cctx.name()).get(hdrKey){code}
that can be simplified with
{code:java}cctx.cache().get(hdrKey){code}


was (Author: xtern):
Hi [~aakhmedov], [~avinogradov].

In GridCacheMultimapImpl I noticed some things that you should pay attention to.

- Iterator of collocated multimap can be slow because it performs full scan of 
shared cache (with another multimap instances). May be this should be described 
in docs.
- Also I noticed a few calls
{code:java}cctx.kernalContext().cache().internalCache(cctx.name()).get(hdrKey){code}
that can be simplified with
{code:java}cctx.cache().get(hdrKey){code}

> Implement IgniteMultimap data structures
> 
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.6
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to 
> {{java.util.Map}} class in JDK, but support the semantics of multiple values 
> per key, similar to [Guava 
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>  
> However, unlike in Guava, our multi-map should work with Lists, not 
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range, 
> between min and max.
> Map getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to 
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
>  and its implementation, 
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value 
> under a separate key in an Ignite cache. For example, let's say that we have 
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should 
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. 
> This means that we need to wrap user key into our own, internal key, which 
> will also have {{index}} field. 
> Also note that we need to collocate all the values for the same key on the 
> same node, which means that we need to define user key K as the affinity key, 
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a 
> specific index to a key and do a cache lookup. Look ups for all values for a 
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v 

[jira] [Commented] (IGNITE-8511) [ML] Add support for Multi-Class Logistic Regression

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8511:


Github user asfgit closed the pull request at:

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


> [ML] Add support for Multi-Class Logistic Regression
> 
>
> Key: IGNITE-8511
> URL: https://issues.apache.org/jira/browse/IGNITE-8511
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
> Fix For: 2.6
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8542) [ML] Add OneVsRest Trainer to handle cases with multiple class labels in dataset

[Yury Babak (JIRA)]

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

Yury Babak updated IGNITE-8542:
---
Description: method extractClassLabels in LogRegressionMultiClassTrainer 
and in SVMLinearMultiClassClassificationTrainer.

> [ML] Add OneVsRest Trainer to handle cases with multiple class labels in 
> dataset
> 
>
> Key: IGNITE-8542
> URL: https://issues.apache.org/jira/browse/IGNITE-8542
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> method extractClassLabels in LogRegressionMultiClassTrainer and in 
> SVMLinearMultiClassClassificationTrainer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8541) Auth: username case sensitive/insensitive behavior is invalid

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-8541:
-
Fix Version/s: (was: 2.6)

> Auth: username case sensitive/insensitive behavior is invalid
> -
>
> Key: IGNITE-8541
> URL: https://issues.apache.org/jira/browse/IGNITE-8541
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, odbc, thin client
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> JDBC thin driver, ODBC driver and Java thin client doesn't support case 
> insensitive behavior for user name when authentication is enabled.
> The user name property already case insensitive.
> The username property must be handled as the *scheme* parameter:
> - quoted user name is case sensitive.
> - nonquoted user name is not case sensitive.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8530) Exchange hangs during start/stop stress test

[Anton Kalashnikov (JIRA)]

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

Anton Kalashnikov reassigned IGNITE-8530:
-

Assignee: Anton Kalashnikov

> Exchange hangs during start/stop stress test
> 
>
> Key: IGNITE-8530
> URL: https://issues.apache.org/jira/browse/IGNITE-8530
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Mikhail Cherkasov
>Assignee: Anton Kalashnikov
>Priority: Major
> Attachments: LocalRunner.java, Main2.java
>
>
> Please see attached test, it starts N_CORES*2+2 nodes first and after this 
> starts N_CORES*2 threads with while(true) cycle in which closes and starts 
> nodes with small random pause.
> After couple minutes it hangs with Failed to wait for partition map exchange.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8542) [ML] Add OneVsRest Trainer to handle cases with multiple class labels in dataset

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8542:


 Summary: [ML] Add OneVsRest Trainer to handle cases with multiple 
class labels in dataset
 Key: IGNITE-8542
 URL: https://issues.apache.org/jira/browse/IGNITE-8542
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8463) Node.js: setup TeamCity

[ekaterina.vergizova (JIRA)]

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

ekaterina.vergizova commented on IGNITE-8463:
-

Seems when the debug was on not all tests were run by TC for unknown reason 
(locally all tests are run even with debug). May be TC has some limitations? 
Now, with debug off, all tests are run and passed.

> Node.js: setup TeamCity
> ---
>
> Key: IGNITE-8463
> URL: https://issues.apache.org/jira/browse/IGNITE-8463
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
>
> Minimal implementation of NodeJS client is almost ready (IGNITE-8014). We 
> need to figure out how to integrate it with TeamCity:
> 1) New suite for NodeJS is needed along with required environment (npm, any 
> recent version). 2) Suite should be able to run Jasmine tests [1]
> 3) Currently all tests rely on manually started external node. We need to 
> create a set of scripts (bash?) to start/stop nodes locally from Jasmine. Raw 
> suggestion: call {{ignite.sh}} with predefined configuration.
> [1] https://jasmine.github.io/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-8466) Control.sh transacitions utility may hang on case with loading

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov closed IGNITE-8466.
---

> Control.sh transacitions utility may hang on case with loading
> --
>
> Key: IGNITE-8466
> URL: https://issues.apache.org/jira/browse/IGNITE-8466
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Priority: Critical
> Attachments: IGNITE-8466.zip
>
>
> Start nodes, activate and preload some Accounts data
>  Start client and run transactional loading (8 threads with ~1000ops/second - 
> moving some amount from one value to another)
>  Start 10 long running transactions (transactions with flexible sleep inside) 
> with label tx_*
>  Start control.sh --tx label tx kill
>  
> Last run of control.sh utility hangs. 
>  
> Attachment info:
>  grid1,2,3 - server logs
> grid20001 - client with preloading
>  grid20002 - client with transactional loading and LRTs (with stack trace)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-8466) Control.sh transacitions utility may hang on case with loading

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov resolved IGNITE-8466.
-
Resolution: Not A Bug

Incorrect test scenario because of unused --force flag

> Control.sh transacitions utility may hang on case with loading
> --
>
> Key: IGNITE-8466
> URL: https://issues.apache.org/jira/browse/IGNITE-8466
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Priority: Critical
> Attachments: IGNITE-8466.zip
>
>
> Start nodes, activate and preload some Accounts data
>  Start client and run transactional loading (8 threads with ~1000ops/second - 
> moving some amount from one value to another)
>  Start 10 long running transactions (transactions with flexible sleep inside) 
> with label tx_*
>  Start control.sh --tx label tx kill
>  
> Last run of control.sh utility hangs. 
>  
> Attachment info:
>  grid1,2,3 - server logs
> grid20001 - client with preloading
>  grid20002 - client with transactional loading and LRTs (with stack trace)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8493:


[~zstan] Hi, yes I'm going to review the change 

> GridToStringBuilder fails with NPE deals with primitive arrays operations.
> --
>
> Key: IGNITE-8493
> URL: https://issues.apache.org/jira/browse/IGNITE-8493
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.6
>
>
> GridToStringBuilder#arrayToString fails with NPE, if input is a primitive 
> array.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8446:


I've checked TC and PR, both look good for me.

> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.6
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny commented on IGNITE-8493:


[~dpavlov], take a look plz?

> GridToStringBuilder fails with NPE deals with primitive arrays operations.
> --
>
> Key: IGNITE-8493
> URL: https://issues.apache.org/jira/browse/IGNITE-8493
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.6
>
>
> GridToStringBuilder#arrayToString fails with NPE, if input is a primitive 
> array.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8463) Node.js: setup TeamCity

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-8463:
--

[~ekaterina.vergizova], some note: after turning debug off, total tests count 
increased from 
[64|https://ci.ignite.apache.org/viewLog.html?buildId=1316067=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs]
 to 
[99|https://ci.ignite.apache.org/viewLog.html?buildId=1316268=buildResultsDiv=IgniteTests24Java8_ThinClientNodeJs].
 Is it predicted behaviour?

> Node.js: setup TeamCity
> ---
>
> Key: IGNITE-8463
> URL: https://issues.apache.org/jira/browse/IGNITE-8463
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
>
> Minimal implementation of NodeJS client is almost ready (IGNITE-8014). We 
> need to figure out how to integrate it with TeamCity:
> 1) New suite for NodeJS is needed along with required environment (npm, any 
> recent version). 2) Suite should be able to run Jasmine tests [1]
> 3) Currently all tests rely on manually started external node. We need to 
> create a set of scripts (bash?) to start/stop nodes locally from Jasmine. Raw 
> suggestion: call {{ignite.sh}} with predefined configuration.
> [1] https://jasmine.github.io/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8316) Update RPM and DEB documentation

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-8316:
--

I've prepared some changes at 
https://dash.readme.io/project/apacheignite/v2.4/docs/getting-started-25.
Yet, final documentation edits will be done on 2.5 release, because only after 
release final repositories' layout and configuration will be clear.

> Update RPM and DEB documentation
> 
>
> Key: IGNITE-8316
> URL: https://issues.apache.org/jira/browse/IGNITE-8316
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.5
>
>
> # Add DEB repository configuration and packages installation.
> # Update RPM repository configuration and packages installation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-5955) Ignite Continuous Query (Queries 3): IgniteCacheContinuousQueryClientReconnectTest fails

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny closed IGNITE-5955.
--

> Ignite Continuous Query (Queries 3): 
> IgniteCacheContinuousQueryClientReconnectTest fails
> 
>
> Key: IGNITE-5955
> URL: https://issues.apache.org/jira/browse/IGNITE-5955
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Stanilovsky Evgeny
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.4, 2.5
>
>
> Reproducible locally with the same exception as on TC.
> In test log there is the following exception:
> {noformat}
> [2017-08-07 
> 03:24:05,694][ERROR][test-runner-#10587%continuous.IgniteCacheContinuousQueryClientReconnectTest%][root]
>  Failed to stop grid 
> [igniteInstanceName=continuous.IgniteCacheContinuousQueryClientReconnectTest0,
>  cancel=true]
> class org.apache.ignite.IgniteClientDisconnectedException: Client node 
> disconnected: continuous.IgniteCacheContinuousQueryClientReconnectTest4
> at 
> org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:92)
> at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3707)
> at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3423)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2105)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1030)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1006)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:997)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.access$200(IgniteCacheContinuousQueryClientReconnectTest.java:42)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest$1.run(IgniteCacheContinuousQueryClientReconnectTest.java:151)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:290)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:221)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.testReconnectClientAndLeftRouter(IgniteCacheContinuousQueryClientReconnectTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> According to [TC 
> history|https://ci.ignite.apache.org/project.html?tab=testDetails_Ignite20Tests=%3Cdefault%3E=Ignite20Tests=9004507841514895830=5]
>  is failing since mid of April.
> Last commit where test has been passing is *b6b3d3754849*.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5789:


Hi [~vk] could I assist in merging conflicts?

> After client reconnects to server if server was restarted, client doesn't 
> create caches defined in client's configuration
> -
>
> Key: IGNITE-5789
> URL: https://issues.apache.org/jira/browse/IGNITE-5789
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Evgenii Zhuravlev
>Assignee: vk
>Priority: Major
> Fix For: 2.6
>
> Attachments: ClientReconnectAfterClusterRestartTest.java
>
>
> User with this problem on SO:
> https://stackoverflow.com/questions/46053089/ignite-cache-reconnection-issue-cache-is-stopped



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8501) Retry on GridServiceNotFoundException in GridServiceProxy needs to be fixed

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8501:


TC run looks as red as usual.

> Retry on GridServiceNotFoundException in GridServiceProxy needs to be fixed
> ---
>
> Key: IGNITE-8501
> URL: https://issues.apache.org/jira/browse/IGNITE-8501
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.6
>
>
> `GridServiceProxy::invokeMethod` attempts to invoke a method of an Ignite 
> service and performs retries in case the invocation procedure throws 
> `GridServiceNotFoundException` or `ClusterTopologyCheckedException` (these 
> exceptions may be thrown in case the service assignments were already 
> calculated, but the service instance was not yet created and initialized on 
> the affinity server).
> After the fix IGNITE-7904 the exception type thrown by the remote invocation 
> code changed to `IgniteCheckedException` (with a cause being 
> `GridServiceNotFoundException` or `ClusterTopologyCheckedException`). Because 
> of that, the retry doesn't work now.
> Need to fix the code to correctly handle new exception chain.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-5955) Ignite Continuous Query (Queries 3): IgniteCacheContinuousQueryClientReconnectTest fails

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-5955:
---
Fix Version/s: 2.4
   2.5

> Ignite Continuous Query (Queries 3): 
> IgniteCacheContinuousQueryClientReconnectTest fails
> 
>
> Key: IGNITE-5955
> URL: https://issues.apache.org/jira/browse/IGNITE-5955
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Stanilovsky Evgeny
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.4, 2.5
>
>
> Reproducible locally with the same exception as on TC.
> In test log there is the following exception:
> {noformat}
> [2017-08-07 
> 03:24:05,694][ERROR][test-runner-#10587%continuous.IgniteCacheContinuousQueryClientReconnectTest%][root]
>  Failed to stop grid 
> [igniteInstanceName=continuous.IgniteCacheContinuousQueryClientReconnectTest0,
>  cancel=true]
> class org.apache.ignite.IgniteClientDisconnectedException: Client node 
> disconnected: continuous.IgniteCacheContinuousQueryClientReconnectTest4
> at 
> org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:92)
> at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3707)
> at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3423)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2105)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1030)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1006)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:997)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.access$200(IgniteCacheContinuousQueryClientReconnectTest.java:42)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest$1.run(IgniteCacheContinuousQueryClientReconnectTest.java:151)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:290)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:221)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.testReconnectClientAndLeftRouter(IgniteCacheContinuousQueryClientReconnectTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> According to [TC 
> history|https://ci.ignite.apache.org/project.html?tab=testDetails_Ignite20Tests=%3Cdefault%3E=Ignite20Tests=9004507841514895830=5]
>  is failing since mid of April.
> Last commit where test has been passing is *b6b3d3754849*.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8054) Let serialize only valuable part of GridLongList

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-8054:
-

[~dpavlov]

Thanks. I will.

> Let serialize only valuable part of GridLongList
> 
>
> Key: IGNITE-8054
> URL: https://issues.apache.org/jira/browse/IGNITE-8054
> Project: Ignite
>  Issue Type: Improvement
>  Components: messaging
>Affects Versions: 2.4
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: easyfix
> Fix For: 2.6
>
>
> Here in GridLongList we serialize all elements and don't take into account 
> `idx` value:
> {code:java}
> @Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 
>     writer.setBuffer(buf); 
>   
>     if (!writer.isHeaderWritten()) { 
>     if (!writer.writeHeader(directType(), fieldsCount())) 
>     return false; 
>   
>     writer.onHeaderWritten(); 
>     } 
>   
>     switch (writer.state()) { 
>     case 0: 
>     if (!writer.writeLongArray("arr", arr)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     case 1: 
>     if (!writer.writeInt("idx", idx)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     } 
>   
>     return true; 
>     } {code}
> Which is not happening in another serialization method in the same class:
> {code:java}
> public static void writeTo(DataOutput out, @Nullable GridLongList list) 
> throws IOException { 
>     out.writeInt(list != null ? list.idx : -1); 
>   
>     if (list != null) { 
>     for (int i = 0; i < list.idx; i++) 
>     out.writeLong(list.arr[i]); 
>     } 
> } {code}
> So, we can simply reduce messages size by sending only a valuable part of the 
> array.
> I created this issue according to a discussion on the mailing list:
> [http://apache-ignite-developers.2346864.n4.nabble.com/Optimize-GridLongList-serialization-td28571.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8354) Ignite Continuosly refreshes Cassandra Session when there is an Exception in execute method of CassandraSessionImpl

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8354:
---
Fix Version/s: 2.6

> Ignite Continuosly refreshes Cassandra Session when there is an Exception in  
> execute method of CassandraSessionImpl
> 
>
> Key: IGNITE-8354
> URL: https://issues.apache.org/jira/browse/IGNITE-8354
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Reporter: Yashasvi Kotamraju
>Assignee: Igor Rudyak
>Priority: Major
> Fix For: 2.6
>
>
> *In CassandraSessionImpl.java* 
> When handlePreparedStatementClusterError method is called during Exception, 
> the session is refreshed.There might be many preparedstatements created with 
> old session(since a session object can be shared between different batches). 
> So when we execute the preparedstatements created with old session on a new 
> session created , we get the the Exception 
> "com.datastax.driver.core.exceptions.InvalidQueryException You may have used 
> a PreparedStatement that was created with another Cluster instance". Which 
> would again call handlePreparedStatementClusterError  and refresh session 
> again and this happens continuously. We have observed continuous cassandra 
> session refresh warnings when this scenario occurred. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)