[jira] [Assigned] (IGNITE-8990) Web console: unexpected 'Unsaved changes' warning
[ https://issues.apache.org/jira/browse/IGNITE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8990: Assignee: Ilya Borisov (was: Alexey Kuznetsov) [~Klaster_1] Could you take a look? > Web console: unexpected 'Unsaved changes' warning > - > > Key: IGNITE-8990 > URL: https://issues.apache.org/jira/browse/IGNITE-8990 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Ilya Borisov >Priority: Major > Attachments: screenshot-1.png > > > My steps were: > # Create a new cluster configuration > # Change Client connector configuration > # Save & Download > # Change the cluster name > # Save & Download > # Go to the Monitoring > I getting the warning about unsaved changes > !screenshot-1.png! > The same issue if I select just Save w\o download. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8990) Web console: unexpected 'Unsaved changes' warning
[ https://issues.apache.org/jira/browse/IGNITE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8990: --- Description: My steps were: # Create a new cluster configuration # Change Client connector configuration # Save & Download # Change the cluster name # Save & Download # Go to the Monitoring I getting the warning about unsaved changes !screenshot-1.png! The same issue if I select just Save w\o download. was: # Create a new cluster configuration # Save # Change the cluster name # Save & Download # Go to the Monitoring I getting the warning about unsaved changes > Web console: unexpected 'Unsaved changes' warning > - > > Key: IGNITE-8990 > URL: https://issues.apache.org/jira/browse/IGNITE-8990 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: screenshot-1.png > > > My steps were: > # Create a new cluster configuration > # Change Client connector configuration > # Save & Download > # Change the cluster name > # Save & Download > # Go to the Monitoring > I getting the warning about unsaved changes > !screenshot-1.png! > The same issue if I select just Save w\o download. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8990) Web console: unexpected 'Unsaved changes' warning
[ https://issues.apache.org/jira/browse/IGNITE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8990: --- Attachment: screenshot-1.png > Web console: unexpected 'Unsaved changes' warning > - > > Key: IGNITE-8990 > URL: https://issues.apache.org/jira/browse/IGNITE-8990 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: screenshot-1.png > > > # Create a new cluster configuration > # Save > # Change the cluster name > # Save & Download > # Go to the Monitoring > I getting the warning about unsaved changes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8990) Web console: unexpected 'Unsaved changes' warning
Pavel Konstantinov created IGNITE-8990: -- Summary: Web console: unexpected 'Unsaved changes' warning Key: IGNITE-8990 URL: https://issues.apache.org/jira/browse/IGNITE-8990 Project: Ignite Issue Type: Bug Components: wizards Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov # Create a new cluster configuration # Save # Change the cluster name # Save & Download # Go to the Monitoring I getting the warning about unsaved changes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8989) Web console: incorrect initial state of some checkboxes on Client Connector Configuration panel
[ https://issues.apache.org/jira/browse/IGNITE-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8989: --- Summary: Web console: incorrect initial state of some checkboxes on Client Connector Configuration panel (was: Web console: incorrect initial state of some checkboxes on Client Configuration panel) > Web console: incorrect initial state of some checkboxes on Client Connector > Configuration panel > --- > > Key: IGNITE-8989 > URL: https://issues.apache.org/jira/browse/IGNITE-8989 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: screenshot-1.png > > > !screenshot-1.png! > These checkboxes should be ON on UI due to its default value in the source > code is true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8989) Web console: incorrect initial state of some checkboxes on Client Configuration panel
[ https://issues.apache.org/jira/browse/IGNITE-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8989: --- Description: !screenshot-1.png! These checkboxes should be ON on UI due to its default value in the source code is true. > Web console: incorrect initial state of some checkboxes on Client > Configuration panel > - > > Key: IGNITE-8989 > URL: https://issues.apache.org/jira/browse/IGNITE-8989 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: screenshot-1.png > > > !screenshot-1.png! > These checkboxes should be ON on UI due to its default value in the source > code is true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8989) Web console: incorrect initial state of some checkboxes on Client Configuration panel
Pavel Konstantinov created IGNITE-8989: -- Summary: Web console: incorrect initial state of some checkboxes on Client Configuration panel Key: IGNITE-8989 URL: https://issues.apache.org/jira/browse/IGNITE-8989 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov Assignee: Vasiliy Sisko Attachments: screenshot-1.png -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8989) Web console: incorrect initial state of some checkboxes on Client Configuration panel
[ https://issues.apache.org/jira/browse/IGNITE-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8989: --- Attachment: screenshot-1.png > Web console: incorrect initial state of some checkboxes on Client > Configuration panel > - > > Key: IGNITE-8989 > URL: https://issues.apache.org/jira/browse/IGNITE-8989 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: screenshot-1.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8988) Web console: error in Readme.txt of generated project
Pavel Konstantinov created IGNITE-8988: -- Summary: Web console: error in Readme.txt of generated project Key: IGNITE-8988 URL: https://issues.apache.org/jira/browse/IGNITE-8988 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov Assignee: Vasiliy Sisko Attachments: screenshot-1.png Readme.txt says XML configuration files are located in /config folder, but actually its located in src/main/resources/META-INF -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8988) Web console: error in Readme.txt of generated project
[ https://issues.apache.org/jira/browse/IGNITE-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8988: --- Description: Readme.txt says XML configuration files are located in /config folder, but actually its located in src/main/resources/META-INF !screenshot-1.png! was:Readme.txt says XML configuration files are located in /config folder, but actually its located in src/main/resources/META-INF > Web console: error in Readme.txt of generated project > - > > Key: IGNITE-8988 > URL: https://issues.apache.org/jira/browse/IGNITE-8988 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Trivial > Attachments: screenshot-1.png > > > Readme.txt says XML configuration files are located in /config folder, but > actually its located in src/main/resources/META-INF > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8988) Web console: error in Readme.txt of generated project
[ https://issues.apache.org/jira/browse/IGNITE-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8988: --- Attachment: screenshot-1.png > Web console: error in Readme.txt of generated project > - > > Key: IGNITE-8988 > URL: https://issues.apache.org/jira/browse/IGNITE-8988 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Trivial > Attachments: screenshot-1.png > > > Readme.txt says XML configuration files are located in /config folder, but > actually its located in src/main/resources/META-INF -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8988) Web console: error in Readme.txt of generated project
[ https://issues.apache.org/jira/browse/IGNITE-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8988: --- Component/s: wizards > Web console: error in Readme.txt of generated project > - > > Key: IGNITE-8988 > URL: https://issues.apache.org/jira/browse/IGNITE-8988 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Trivial > Attachments: screenshot-1.png > > > Readme.txt says XML configuration files are located in /config folder, but > actually its located in src/main/resources/META-INF -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8982) SQL TX: reuse H2 connections
[ https://issues.apache.org/jira/browse/IGNITE-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ruchir choudhry reassigned IGNITE-8982: --- Assignee: ruchir choudhry > SQL TX: reuse H2 connections > > > Key: IGNITE-8982 > URL: https://issues.apache.org/jira/browse/IGNITE-8982 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Pavlukhin >Assignee: ruchir choudhry >Priority: Major > > H2 Connection creation is not very fast. Reusing already created connections > could speed up execution in several cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8982) SQL TX: reuse H2 connections
[ https://issues.apache.org/jira/browse/IGNITE-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540914#comment-16540914 ] ruchir choudhry commented on IGNITE-8982: - [~Pavlukhin] : If you can help me with the flow a bit, I can take this up. > SQL TX: reuse H2 connections > > > Key: IGNITE-8982 > URL: https://issues.apache.org/jira/browse/IGNITE-8982 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Pavlukhin >Priority: Major > > H2 Connection creation is not very fast. Reusing already created connections > could speed up execution in several cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7802) Clarify how to hook Ignite and a 3rd party persistence
[ https://issues.apache.org/jira/browse/IGNITE-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540732#comment-16540732 ] Prachi Garg commented on IGNITE-7802: - [~dmagda], please review - https://apacheignite.readme.io/v2.5/docs/3rd-party-persistence-27 > Clarify how to hook Ignite and a 3rd party persistence > -- > > Key: IGNITE-7802 > URL: https://issues.apache.org/jira/browse/IGNITE-7802 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > > The existing documentation doesn't explain all the steps needed to integrate > Ignite with a 3rd party db: > [https://apacheignite.readme.io/docs/3rd-party-store] > Specifically, the following has to be covered: > * Dedicated section for RDBMS setup. Copying of a JDBC driver, enabling a > right CacheStore implementation, defining the mapping, or automating this > process with Web Console. > * NoSQL databases section. Refer to Cassandra pages. > * Other 3rd party stores. Clarify how to write a custom CacheStore that is > not supported out of the box. > The goal is to avoid questions like this: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-with-mariadb-td20101.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7802) Clarify how to hook Ignite and a 3rd party persistence
[ https://issues.apache.org/jira/browse/IGNITE-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-7802: --- Assignee: Denis Magda (was: Prachi Garg) > Clarify how to hook Ignite and a 3rd party persistence > -- > > Key: IGNITE-7802 > URL: https://issues.apache.org/jira/browse/IGNITE-7802 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > The existing documentation doesn't explain all the steps needed to integrate > Ignite with a 3rd party db: > [https://apacheignite.readme.io/docs/3rd-party-store] > Specifically, the following has to be covered: > * Dedicated section for RDBMS setup. Copying of a JDBC driver, enabling a > right CacheStore implementation, defining the mapping, or automating this > process with Web Console. > * NoSQL databases section. Refer to Cassandra pages. > * Other 3rd party stores. Clarify how to write a custom CacheStore that is > not supported out of the box. > The goal is to avoid questions like this: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-with-mariadb-td20101.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4159) Cloud Native Deployment of Apache Ignite using Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-4159. - Resolution: Fixed > Cloud Native Deployment of Apache Ignite using Kubernetes > - > > Key: IGNITE-4159 > URL: https://issues.apache.org/jira/browse/IGNITE-4159 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > > Kubernetes is an open-source system for automating deployment, scaling, and > management of containerized applications. > http://kubernetes.io > Apache Ignite perfectly fits the concepts implemented in Kubernetes which may > greatly simplify and automate the maintenance and scaling of Apache Ignite > clusters running under the supervision of Kubernetes. > Ignite won't be the first distributed storage that supports Kubernetes. There > are already a number of existed ones that being used: > https://github.com/kubernetes/kubernetes/tree/master/examples/storage/cassandra > https://github.com/pires/hazelcast-kubernetes > https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes > This is an umbrella ticket that incorporates all the works that have to be > done before Ignite officially claims that it can be launched under Kubernetes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5347) Document enums usage in SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-5347: --- Assignee: (was: Denis Magda) > Document enums usage in SQL queries > --- > > Key: IGNITE-5347 > URL: https://issues.apache.org/jira/browse/IGNITE-5347 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Priority: Major > Labels: documentation > > Here is a documentation to be added to this page > (https://apacheignite.readme.io/v2.0/docs/distributed-queries-21): > If a field is of a Java enum type, then you can pass the field's value as a > parameter via standard `?` keyword or use enum's literal or ordinal value > directly, as shown in the example below: > // SQL query with the field of Java enum type. > SqlFieldsQuery sql = new SqlFieldsQuery( > "SELECT name FROM Person WHERE role = 'DEVELOPER' or role = 2"); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4749) Advanced testing of Kubernetes IP finder
[ https://issues.apache.org/jira/browse/IGNITE-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-4749. - Resolution: Not A Problem > Advanced testing of Kubernetes IP finder > > > Key: IGNITE-4749 > URL: https://issues.apache.org/jira/browse/IGNITE-4749 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Denis Magda >Priority: Major > > Test coverage of Kubernetes IP finder has to be extended. We need to find a > way on how to start a Kubernetes single node cluster as a part of unit tests > and check the following: > - Ignite pods are able to discover each other. > - The cluster can be scaled out or scaled in using standard Kubernetes API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-4749) Advanced testing of Kubernetes IP finder
[ https://issues.apache.org/jira/browse/IGNITE-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-4749. --- > Advanced testing of Kubernetes IP finder > > > Key: IGNITE-4749 > URL: https://issues.apache.org/jira/browse/IGNITE-4749 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Denis Magda >Priority: Major > > Test coverage of Kubernetes IP finder has to be extended. We need to find a > way on how to start a Kubernetes single node cluster as a part of unit tests > and check the following: > - Ignite pods are able to discover each other. > - The cluster can be scaled out or scaled in using standard Kubernetes API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-4159) Cloud Native Deployment of Apache Ignite using Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-4159. --- > Cloud Native Deployment of Apache Ignite using Kubernetes > - > > Key: IGNITE-4159 > URL: https://issues.apache.org/jira/browse/IGNITE-4159 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > > Kubernetes is an open-source system for automating deployment, scaling, and > management of containerized applications. > http://kubernetes.io > Apache Ignite perfectly fits the concepts implemented in Kubernetes which may > greatly simplify and automate the maintenance and scaling of Apache Ignite > clusters running under the supervision of Kubernetes. > Ignite won't be the first distributed storage that supports Kubernetes. There > are already a number of existed ones that being used: > https://github.com/kubernetes/kubernetes/tree/master/examples/storage/cassandra > https://github.com/pires/hazelcast-kubernetes > https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes > This is an umbrella ticket that incorporates all the works that have to be > done before Ignite officially claims that it can be launched under Kubernetes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6716) Document "Affinity key backups mismatch" resolution steps
[
https://issues.apache.org/jira/browse/IGNITE-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-6716:
---
Assignee: Artem Budnikov (was: Denis Magda)
> Document "Affinity key backups mismatch" resolution steps
> -
>
> Key: IGNITE-6716
> URL: https://issues.apache.org/jira/browse/IGNITE-6716
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Nicholas DiPiazza
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> Please see the issue below:
> https://stackoverflow.com/questions/46894435/how-do-i-fix-affinity-key-backups-in-cache-configuration
> results in this error:
> {code}
> org.apache.ignite.IgniteCheckedException: Affinity key backups mismatch (fix
> affinity key backups in cache configuration or set
> -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property)
> {code}
> Can someone help me get the steps in order to fix this issue? we should add
> it to the documentation somewhere.
> # What causes this error?
> # How to fix this error?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6716) Document "Affinity key backups mismatch" resolution steps
[
https://issues.apache.org/jira/browse/IGNITE-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6716:
Fix Version/s: 2.7
> Document "Affinity key backups mismatch" resolution steps
> -
>
> Key: IGNITE-6716
> URL: https://issues.apache.org/jira/browse/IGNITE-6716
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Nicholas DiPiazza
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.7
>
>
> Please see the issue below:
> https://stackoverflow.com/questions/46894435/how-do-i-fix-affinity-key-backups-in-cache-configuration
> results in this error:
> {code}
> org.apache.ignite.IgniteCheckedException: Affinity key backups mismatch (fix
> affinity key backups in cache configuration or set
> -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property)
> {code}
> Can someone help me get the steps in order to fix this issue? we should add
> it to the documentation somewhere.
> # What causes this error?
> # How to fix this error?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6716) Document "Affinity key backups mismatch" resolution steps
[
https://issues.apache.org/jira/browse/IGNITE-6716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540688#comment-16540688
]
Denis Magda commented on IGNITE-6716:
-
[~Artem Budnikov], could you look into this please?
> Document "Affinity key backups mismatch" resolution steps
> -
>
> Key: IGNITE-6716
> URL: https://issues.apache.org/jira/browse/IGNITE-6716
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Nicholas DiPiazza
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> Please see the issue below:
> https://stackoverflow.com/questions/46894435/how-do-i-fix-affinity-key-backups-in-cache-configuration
> results in this error:
> {code}
> org.apache.ignite.IgniteCheckedException: Affinity key backups mismatch (fix
> affinity key backups in cache configuration or set
> -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property)
> {code}
> Can someone help me get the steps in order to fix this issue? we should add
> it to the documentation somewhere.
> # What causes this error?
> # How to fix this error?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7645) Clarify eviction policy documentation
[ https://issues.apache.org/jira/browse/IGNITE-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7645: --- Assignee: Artem Budnikov (was: Denis Magda) > Clarify eviction policy documentation > - > > Key: IGNITE-7645 > URL: https://issues.apache.org/jira/browse/IGNITE-7645 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > Eviction policies work differently depending on the configuration that might > be one of the following: > * Just off-heap memory w/o Ignite persistence > * off-heap memory + on-heap cache > * off-heap memory + Ignite persistence > * off-heap memory + swap or cache store > Cover all these scenarios on the main eviction doc > page:https://apacheignite.readme.io/docs/evictions > More details: > http://apache-ignite-developers.2346864.n4.nabble.com/Eviction-policies-with-persistence-td26588.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7645) Clarify eviction policy documentation
[ https://issues.apache.org/jira/browse/IGNITE-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7645: Fix Version/s: (was: 2.4) 2.7 > Clarify eviction policy documentation > - > > Key: IGNITE-7645 > URL: https://issues.apache.org/jira/browse/IGNITE-7645 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > Eviction policies work differently depending on the configuration that might > be one of the following: > * Just off-heap memory w/o Ignite persistence > * off-heap memory + on-heap cache > * off-heap memory + Ignite persistence > * off-heap memory + swap or cache store > Cover all these scenarios on the main eviction doc > page:https://apacheignite.readme.io/docs/evictions > More details: > http://apache-ignite-developers.2346864.n4.nabble.com/Eviction-policies-with-persistence-td26588.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8396) Update documentation for kNN classification (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8396. --- > Update documentation for kNN classification (release 2.5) > - > > Key: IGNITE-8396 > URL: https://issues.apache.org/jira/browse/IGNITE-8396 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Aleksey Zinoviev >Assignee: Denis Magda >Priority: Major > > In Apache Ignite 2.5 we have changed a kNN classification working on top of > partition based dataset and now we need to update documentation for this > feature. > > Previous version: > [https://dash.readme.io/project/apacheignite/v2.4/docs/knn-classification] > update with > New version: > [https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-classification-25] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8398) Update documentation for KMeans clustering (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8398. --- > Update documentation for KMeans clustering (release 2.5) > > > Key: IGNITE-8398 > URL: https://issues.apache.org/jira/browse/IGNITE-8398 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Aleksey Zinoviev >Assignee: Denis Magda >Priority: Major > > In Apache Ignite 2.5 we have changed a kMeans clustering and remove > FuzzyCMeans working on top of partition based dataset and now we need to > update documentation for this feature. > > Previous version: > [https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering] > update with > New version: > [https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering-25] > > IMPORTANT: Remove page > [https://dash.readme.io/project/apacheignite/v2.4/docs/fuzzy-c-means-clustering] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8397) Update documentation for kNN regression (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8397. --- > Update documentation for kNN regression (release 2.5) > - > > Key: IGNITE-8397 > URL: https://issues.apache.org/jira/browse/IGNITE-8397 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Aleksey Zinoviev >Assignee: Denis Magda >Priority: Major > > In Apache Ignite 2.5 we have changed a kNN regression working on top of > partition based dataset and now we need to update documentation for this > feature. > > Previous version: > [https://dash.readme.io/project/apacheignite/v2.4/docs/knn-regression] > update with > New version: > [https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-regression-25] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8398) Update documentation for KMeans clustering (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540681#comment-16540681 ] Denis Magda commented on IGNITE-8398: - [~abchaudhri], you need to mention [~pgarg] directly and assign the ticket to her to bring it to her attention. > Update documentation for KMeans clustering (release 2.5) > > > Key: IGNITE-8398 > URL: https://issues.apache.org/jira/browse/IGNITE-8398 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Aleksey Zinoviev >Assignee: Denis Magda >Priority: Major > > In Apache Ignite 2.5 we have changed a kMeans clustering and remove > FuzzyCMeans working on top of partition based dataset and now we need to > update documentation for this feature. > > Previous version: > [https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering] > update with > New version: > [https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering-25] > > IMPORTANT: Remove page > [https://dash.readme.io/project/apacheignite/v2.4/docs/fuzzy-c-means-clustering] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8399) Add documentation for SVM Binary and Multi-class classification (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8399. --- > Add documentation for SVM Binary and Multi-class classification (release 2.5) > - > > Key: IGNITE-8399 > URL: https://issues.apache.org/jira/browse/IGNITE-8399 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Aleksey Zinoviev >Assignee: Denis Magda >Priority: Major > > In Apache Ignite 2.5 we have added a SVM Binary and Multi-class > classification working on top of partition based dataset and now we need to > update documentation for this feature. > Add page [https://dash.readme.io/project/apacheignite/v2.4/docs/svm-25] > Add page > [https://dash.readme.io/project/apacheignite/v2.4/docs/svm-multi-class-classification-25] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540680#comment-16540680 ] Denis Magda commented on IGNITE-8411: - [~isapego], have we incorporated the changes suggested by Alexey in this ticket? > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8455) Cover main Ignite memory modes
[ https://issues.apache.org/jira/browse/IGNITE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8455. --- > Cover main Ignite memory modes > -- > > Key: IGNITE-8455 > URL: https://issues.apache.org/jira/browse/IGNITE-8455 > Project: Ignite > Issue Type: Task > Components: site >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > Ignite website doesn't mention various modes on how Ignite native persistence > can be used: > - no disk, data is in memory-only (potentially over a 3rd-party database) > - disk is a copy of the memory (only for recovery purposes) > - disk is a data storage with memory used as a performant caching layer > - indexes in memory and data on disk for better technical cost of ownership. > I believe we should put it in a table and explain it on the memory-centric > page. > More details: > http://apache-ignite-developers.2346864.n4.nabble.com/missing-website-info-td30145.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-8411: Fix Version/s: 2.7 > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8411: --- Assignee: Igor Sapego (was: Denis Magda) > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7758) Update REST documentation
[ https://issues.apache.org/jira/browse/IGNITE-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-7758. --- > Update REST documentation > - > > Key: IGNITE-7758 > URL: https://issues.apache.org/jira/browse/IGNITE-7758 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.5 >Reporter: Alexey Kuznetsov >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > RETS documentation need to be updated: > # GET_OR_CREATE_CACHE enhanced command with optional "templateName", > "backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options. > # Added support for Java built in types for put/get operations via > "keyType" and "valueType" optional parameters. List of supported types: > * java.lang.Boolean (with alias boolean) > * java.lang.Byte (with alias byte) > * java.lang.Short (with alias short) > * java.lang.Integer (with aliases int, integer) > * java.lang.Long (with alias long) > * java.lang.Float (with alias float) > * java.lang.Double (with alias double) > * java.sql.Date (with alias date) > * java.sql.Time (with alias time) > * java.sql.Timestamp (with alias timestamp) > * java.util.UUUID (with alias uuid) > * org.apache.ignite.lang.IgniteUuid (with alias IgniteUuid) > For Date, Time, Timestamp value should be in format as specified in > *valueOf(String)* methods of corresponding classes. > Example for date: "2018-01-01" see > https://docs.oracle.com/javase/8/docs/api/java/sql/Date.html#valueOf-java.lang.String- > Example for time: "01:01:01" see > https://docs.oracle.com/javase/8/docs/api/java/sql/Time.html#valueOf-java.lang.String- > Example for timestamp: "2018-02-18%2001:01:01" see > https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#valueOf-java.lang.String- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8455) Cover main Ignite memory modes
[ https://issues.apache.org/jira/browse/IGNITE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-8455. - Resolution: Fixed Done. Added to the memory-centric page: https://ignite.apache.org/arch/memorycentric.html > Cover main Ignite memory modes > -- > > Key: IGNITE-8455 > URL: https://issues.apache.org/jira/browse/IGNITE-8455 > Project: Ignite > Issue Type: Task > Components: site >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > > Ignite website doesn't mention various modes on how Ignite native persistence > can be used: > - no disk, data is in memory-only (potentially over a 3rd-party database) > - disk is a copy of the memory (only for recovery purposes) > - disk is a data storage with memory used as a performant caching layer > - indexes in memory and data on disk for better technical cost of ownership. > I believe we should put it in a table and explain it on the memory-centric > page. > More details: > http://apache-ignite-developers.2346864.n4.nabble.com/missing-website-info-td30145.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8081) Document Kubernetes RBAC configuration to avoid 403 exception
[ https://issues.apache.org/jira/browse/IGNITE-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-8081. - Resolution: Fixed > Document Kubernetes RBAC configuration to avoid 403 exception > - > > Key: IGNITE-8081 > URL: https://issues.apache.org/jira/browse/IGNITE-8081 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.7 > > > It's reported by the users that sometimes Ignite Kubernetes IP finder fails > to join the cluster due to security issues. To prevent the exception > happening we need to document how to set up a Service Account for Ignite pods: > https://stackoverflow.com/questions/49395481/how-to-setmasterurl-in-ignite-xml-config-for-kubernetes-ipfinder/49405879#49405879 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8081) Document Kubernetes RBAC configuration to avoid 403 exception
[ https://issues.apache.org/jira/browse/IGNITE-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8081. --- > Document Kubernetes RBAC configuration to avoid 403 exception > - > > Key: IGNITE-8081 > URL: https://issues.apache.org/jira/browse/IGNITE-8081 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.7 > > > It's reported by the users that sometimes Ignite Kubernetes IP finder fails > to join the cluster due to security issues. To prevent the exception > happening we need to document how to set up a Service Account for Ignite pods: > https://stackoverflow.com/questions/49395481/how-to-setmasterurl-in-ignite-xml-config-for-kubernetes-ipfinder/49405879#49405879 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8976) Add native persistence section to Key-Value data grid page
[ https://issues.apache.org/jira/browse/IGNITE-8976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg updated IGNITE-8976: Priority: Trivial (was: Blocker) > Add native persistence section to Key-Value data grid page > -- > > Key: IGNITE-8976 > URL: https://issues.apache.org/jira/browse/IGNITE-8976 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Dmitriy Setrakyan >Assignee: Prachi Garg >Priority: Trivial > Fix For: 2.7 > > > Main goal - less text, better structure. > # We need to add a section for Ignite native persistence > # We need to add a native persistence image to this section. > # We need to place current 3rd party DB image next to the 3rd party DB > section > # We need to add a section for collocation - compute + data and data + data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8987) Ignite hangs during getting of atomic structure after autoactivation
Andrey Aleksandrov created IGNITE-8987: -- Summary: Ignite hangs during getting of atomic structure after autoactivation Key: IGNITE-8987 URL: https://issues.apache.org/jira/browse/IGNITE-8987 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.4 Reporter: Andrey Aleksandrov Fix For: 2.7 Attachments: reproducer.java I investigate the use cases with autoactivation and creating of the IgniteAtomicSequence. It hangs on awaitInitialization() method in case if it called after the last node from BLT was started. Steps to reproduce: First iteration: Do next in one thread: 1)Start server 1 2)Start server 2 3)Activate the cluster 4)Create the IgniteAtomicSequence using next code: IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( "TestName", atomicConfiguration, 10, true); Second iteration: 1)Start server 1 2)Start server 2 (Autoactivation will be started) 3)Get the IgniteAtomicSequence using next code: IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( "TestName", 10, true); //could be false because TestName was already created in iteration 1 In this case, we hang in awaitInitialization() method in DataStructureProcessor.getAtomic() method. In case if I added some sleep timeout between step 2 and 3 in the second iteration then everything was ok. Looks like we have some race here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8955) Checkpoint can't get write lock if massive eviction on node start started
[ https://issues.apache.org/jira/browse/IGNITE-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540358#comment-16540358 ] Ivan Rakov commented on IGNITE-8955: Changes look good. Merged to master. > Checkpoint can't get write lock if massive eviction on node start started > - > > Key: IGNITE-8955 > URL: https://issues.apache.org/jira/browse/IGNITE-8955 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.7 > > > Many sys-threads start eviction and start being throttled, so they couldn't > proceed because of it, while checkpoint couldn't start because they hold > checkpoint read lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8955) Checkpoint can't get write lock if massive eviction on node start started
[ https://issues.apache.org/jira/browse/IGNITE-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov resolved IGNITE-8955. Resolution: Fixed > Checkpoint can't get write lock if massive eviction on node start started > - > > Key: IGNITE-8955 > URL: https://issues.apache.org/jira/browse/IGNITE-8955 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.7 > > > Many sys-threads start eviction and start being throttled, so they couldn't > proceed because of it, while checkpoint couldn't start because they hold > checkpoint read lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8955) Checkpoint can't get write lock if massive eviction on node start started
[ https://issues.apache.org/jira/browse/IGNITE-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8955: --- Fix Version/s: 2.7 > Checkpoint can't get write lock if massive eviction on node start started > - > > Key: IGNITE-8955 > URL: https://issues.apache.org/jira/browse/IGNITE-8955 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.7 > > > Many sys-threads start eviction and start being throttled, so they couldn't > proceed because of it, while checkpoint couldn't start because they hold > checkpoint read lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8986) Need to add configuration validation template on startup
Dmitriy Setrakyan created IGNITE-8986: - Summary: Need to add configuration validation template on startup Key: IGNITE-8986 URL: https://issues.apache.org/jira/browse/IGNITE-8986 Project: Ignite Issue Type: Improvement Components: general Reporter: Dmitriy Setrakyan Assignee: Vladimir Ozerov Fix For: 2.7 We should have a validation template file (e.g. ignite-validate.xml), and make sure on startup that all config properties specified in that file match. This way a user could put this file somewhere on a shared network drive and have an extra degree of confidence that the configuration is valid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
Mikhail Cherkasov created IGNITE-8985: - Summary: Node segmented itself after connRecoveryTimeout Key: IGNITE-8985 URL: https://issues.apache.org/jira/browse/IGNITE-8985 Project: Ignite Issue Type: Bug Reporter: Mikhail Cherkasov Attachments: Archive.zip I can see the following message in logs: [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect to next nodes in a ring, it seems local node is experiencing connectivity issues. Segmenting local node to avoid case when one node fails a big part of cluster. To disable that behavior set TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, ver=2.4.7#20180710-sha1:a48ae923, isClient=false] I have failure detection time out 60_000 and during the test I had GC <25secs, so I don't expect that node should be segmented. Logs are attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
[ https://issues.apache.org/jira/browse/IGNITE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540324#comment-16540324 ] ASF GitHub Bot commented on IGNITE-8905: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4288 > Incorrect assertion in GridDhtPartitionsExchangeFuture > -- > > Key: IGNITE-8905 > URL: https://issues.apache.org/jira/browse/IGNITE-8905 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > Original Estimate: 2h > Time Spent: 2h > Remaining Estimate: 59m > > Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture > which is correct only in situation when client has to reconnect due to too > short EXCHANGE_HISTORY. > Exceptions from other situations like not being able to acquire file lock are > also passed to client node in FullMessage. > This assertion should be removed and check should be introduced instead: if > this exception is intended to be thrown on current client node, we should do > this, otherwise old program flow should be executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8984) Ignite 2.5 - Vulnerabilities
Segu Riluvan created IGNITE-8984: Summary: Ignite 2.5 - Vulnerabilities Key: IGNITE-8984 URL: https://issues.apache.org/jira/browse/IGNITE-8984 Project: Ignite Issue Type: Bug Reporter: Segu Riluvan Attachments: Ignite_2_5_Blackduck_Scan_4_Github.zip Recently we have scanned Apache Ignite 2.5 source code and all the associated maven packages using Blackduck. The scan identified with many of the dependencies for Ignite 2.5. Many of these vulnerabilities are rated as High risk vulnerabilities. I've attached the vulnerability report to this ticket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8946) AssertionError can occur during release of WAL history that was reserved for historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540275#comment-16540275
]
Ivan Rakov commented on IGNITE-8946:
[~ilantukh], thanks for your review!
My test has specific logic that is needed to reproduce the issue. I've renamed
the test class accordingly and added it to the suite.
Changes are merged to master.
> AssertionError can occur during release of WAL history that was reserved for
> historical rebalance
> -
>
> Key: IGNITE-8946
> URL: https://issues.apache.org/jira/browse/IGNITE-8946
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.7
>
>
> Attempt to release WAL history after exchange may fail with AssertionError.
> Seems like we have a bug and may try to release more WAL segments than we
> have reserved:
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage.release(SegmentReservationStorage.java:54)
> - locked <0x1c12> (a
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.release(FileWriteAheadLogManager.java:862)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.releaseHistoryForExchange(GridCacheDatabaseSharedManager.java:1691)
> - locked <0x1c17> (a
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2858)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2591)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2283)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:129)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2140)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2128)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2128)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1580)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:345)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:325)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2848)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2827)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
>
[jira] [Commented] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
[ https://issues.apache.org/jira/browse/IGNITE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540276#comment-16540276 ] Sergey Chugunov commented on IGNITE-8905: - [~Mmuzaf], Could you send me a link to TC run with failed test? I don't see it in TC report, this particular test seems passing: [link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache5_IgniteTests24Java8=pull%2F4288%2Fhead=buildTypeStatusDiv] > Incorrect assertion in GridDhtPartitionsExchangeFuture > -- > > Key: IGNITE-8905 > URL: https://issues.apache.org/jira/browse/IGNITE-8905 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > Original Estimate: 2h > Time Spent: 2h > Remaining Estimate: 59m > > Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture > which is correct only in situation when client has to reconnect due to too > short EXCHANGE_HISTORY. > Exceptions from other situations like not being able to acquire file lock are > also passed to client node in FullMessage. > This assertion should be removed and check should be introduced instead: if > this exception is intended to be thrown on current client node, we should do > this, otherwise old program flow should be executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8946) AssertionError can occur during release of WAL history that was reserved for historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540228#comment-16540228
]
Ilya Lantukh commented on IGNITE-8946:
--
[~ivan.glukos],
Please move your test to IgniteWalHistoryReservationsTest class or, if you find
it too complex, add your class to test suite.
Changes in logic look good.
> AssertionError can occur during release of WAL history that was reserved for
> historical rebalance
> -
>
> Key: IGNITE-8946
> URL: https://issues.apache.org/jira/browse/IGNITE-8946
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.7
>
>
> Attempt to release WAL history after exchange may fail with AssertionError.
> Seems like we have a bug and may try to release more WAL segments than we
> have reserved:
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage.release(SegmentReservationStorage.java:54)
> - locked <0x1c12> (a
> org.apache.ignite.internal.processors.cache.persistence.wal.SegmentReservationStorage)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.release(FileWriteAheadLogManager.java:862)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.releaseHistoryForExchange(GridCacheDatabaseSharedManager.java:1691)
> - locked <0x1c17> (a
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2858)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2591)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2283)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:129)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2140)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2128)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2128)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1580)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:345)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:325)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2848)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2827)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
>
[jira] [Commented] (IGNITE-8965) Add logs in SegmentReservationStorage on exchange process
[ https://issues.apache.org/jira/browse/IGNITE-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540209#comment-16540209 ] Ivan Rakov commented on IGNITE-8965: Looks good, merged to master. > Add logs in SegmentReservationStorage on exchange process > - > > Key: IGNITE-8965 > URL: https://issues.apache.org/jira/browse/IGNITE-8965 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540197#comment-16540197
]
Alexey Goncharuk commented on IGNITE-8957:
--
As for the format, I'm fine with both the last segment and segment range
{{5-8}}, but personally I would prefer that segments range is printed out.
If the cleared segments printout change is rather big, then we need a separate
task. Otherwise it is ok to change it in this ticket.
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540196#comment-16540196
]
Maxim Muzafarov commented on IGNITE-8957:
-
[~agoncharuk]
Current format:
{{Checkpoint finished [cpId=4669a320-5184-4382-ae08-afb8599a1ee1, pages=33311,
markPos=FileWALPointer [idx=22, fileOff=5441449, len=21409],
{color:#FF}walSegmentsCleared=4, walSegmentsCovered=[17, 18, 19, 20,
21],{color} markDuration=44ms, pagesWrite=235ms, fsync=490ms, total=770ms]}}
Vote for (or another separator):
{{Checkpoint finished [cpId=4669a320-5184-4382-ae08-afb8599a1ee1, pages=33311,
markPos=FileWALPointer [idx=22, fileOff=5441449, len=21409],
{color:#FF}walSegmentsCleared=[13...16],
walSegmentsCovered=[17...21],{color} markDuration=44ms, pagesWrite=235ms,
fsync=490ms, total=770ms]}}
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8776) Eviction policy MBeans are never registered if evictionPolicyFactory is used
[ https://issues.apache.org/jira/browse/IGNITE-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540188#comment-16540188 ] kcheng.mvp commented on IGNITE-8776: [~dpavlov] Can you please take a look about this PR. it has been passed [~slukyanov] 's review. > Eviction policy MBeans are never registered if evictionPolicyFactory is used > > > Key: IGNITE-8776 > URL: https://issues.apache.org/jira/browse/IGNITE-8776 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Stanislav Lukyanov >Assignee: kcheng.mvp >Priority: Minor > Labels: newbie > Fix For: 2.7 > > > Eviction policy MBeans, such as LruEvictionPolicyMBean, are never registered > if evictionPolicyFactory is set instead of evictionPolicy (the latter is > deprecated). > This happens because GridCacheProcessor::registerMbean attempts to find > either an *MBean interface or IgniteMBeanAware interface on the passed > object. It works for LruEvictionPolicy but not for LruEvictionPolicyFactory > (which doesn't implement these interfaces). > The code needs to be adjusted to handle factories correctly. > New tests are needed to make sure that all standard beans are registered > (IgniteKernalMbeansTest does that for kernal mbeans - need the same for cache > beans). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8968) Failed to shutdown node due to "Error saving backup value"
[ https://issues.apache.org/jira/browse/IGNITE-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540179#comment-16540179 ] Pavel Vinokurov edited comment on IGNITE-8968 at 7/11/18 2:44 PM: -- [~mcherkasov] Probably there are possible other exceptions like CacheStoppedException or StorageException. So the main question is to should we escalate the error by throwing IgniteException or remain backup not initialized in case of error. was (Author: pvinokurov): [~mcherkasov] Probably there are possible other exceptions like CacheStoppedException or exception related to WAL. So the main question is to should we escalate the error by throwing IgniteException or remain backup not initialized in case of error. > Failed to shutdown node due to "Error saving backup value" > -- > > Key: IGNITE-8968 > URL: https://issues.apache.org/jira/browse/IGNITE-8968 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > On node shutdown ignite prints following logs infinitely: > org.apache.ignite.internal.NodeStoppingException: Operation has been > cancelled (node is stopping). > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3626) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2783) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.process(GridCacheUtils.java:1734) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:1782) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:1724) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540186#comment-16540186
]
Alexey Goncharuk commented on IGNITE-8957:
--
[~andmed], [~Mmuzaf] Could you please add an example of the message that will
be printed out to this ticket?
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8968) Failed to shutdown node due to "Error saving backup value"
[ https://issues.apache.org/jira/browse/IGNITE-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540179#comment-16540179 ] Pavel Vinokurov edited comment on IGNITE-8968 at 7/11/18 2:43 PM: -- [~mcherkasov] Probably there are possible other exceptions like CacheStoppedException or exception related to WAL. So the main question is to should we escalate the error by throwing IgniteException or remain backup not initialized in case of error. was (Author: pvinokurov): [~mcherkasov] Probably there are possible other exceptions like CacheStoppedException. So the main question is to should we escalate the error by throwing IgniteException or remain backup not initialized in case of error. > Failed to shutdown node due to "Error saving backup value" > -- > > Key: IGNITE-8968 > URL: https://issues.apache.org/jira/browse/IGNITE-8968 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > On node shutdown ignite prints following logs infinitely: > org.apache.ignite.internal.NodeStoppingException: Operation has been > cancelled (node is stopping). > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3626) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2783) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.process(GridCacheUtils.java:1734) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:1782) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:1724) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540183#comment-16540183
]
Maxim Muzafarov commented on IGNITE-8957:
-
[~akalashnikov],
Nice notion! I'm voting for printing first and last id of segments in clear for
reading logs format e.g. {{[5 - 8]}} or {{from 5 to 8}}.
Also, I think nice to have the same printing format for cleared segments.
May be we should create separate task for it?
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8968) Failed to shutdown node due to "Error saving backup value"
[ https://issues.apache.org/jira/browse/IGNITE-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540179#comment-16540179 ] Pavel Vinokurov commented on IGNITE-8968: - [~mcherkasov] Probably there are possible other exceptions like CacheStoppedException. So the main question is to should we escalate the error by throwing IgniteException or remain backup not initialized in case of error. > Failed to shutdown node due to "Error saving backup value" > -- > > Key: IGNITE-8968 > URL: https://issues.apache.org/jira/browse/IGNITE-8968 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > On node shutdown ignite prints following logs infinitely: > org.apache.ignite.internal.NodeStoppingException: Operation has been > cancelled (node is stopping). > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3626) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2783) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.process(GridCacheUtils.java:1734) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:1782) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$22.apply(GridCacheUtils.java:1724) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8945) Stored cache data files corruption when node stops abruptly.
[ https://issues.apache.org/jira/browse/IGNITE-8945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540180#comment-16540180 ] ASF GitHub Bot commented on IGNITE-8945: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4319 > Stored cache data files corruption when node stops abruptly. > > > Key: IGNITE-8945 > URL: https://issues.apache.org/jira/browse/IGNITE-8945 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.7 > > > When node is halted during saving stored cache data, content of this file can > be corrupted. > 1. Additional check should be implemented in > FilePageStoreManager.readCacheData > (print the name of corrupted file) > 2. In storeCacheData we need to serialize StoredCacheData to temp file then > swap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7366) Affinity assignment exception in service processor during multiple nodes join
[
https://issues.apache.org/jira/browse/IGNITE-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540166#comment-16540166
]
ASF GitHub Bot commented on IGNITE-7366:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4321
> Affinity assignment exception in service processor during multiple nodes join
> -
>
> Key: IGNITE-7366
> URL: https://issues.apache.org/jira/browse/IGNITE-7366
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.7
>
>
> When two nodes which are deploying services join at the same time, and
> exception is observed:
> {code}
> SEVERE: Error when executing service: null
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=245d4bec-0384-4808-b66d-d2340930207f..., discPort=37500, order=2,
> intOrder=2, lastExchangeTime=1515394551283, loc=true,
> ver=2.3.0#20171028-sha1:8add7fd5, isClient=false], grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0],
> head=AffinityTopologyVersion [topVer=4, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=2, minorTopVer=0],
> AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion
> [topVer=4, minorTopVer=0]]]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:514)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:419)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:220)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:256)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:247)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:271)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1771)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1958)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> This may be caused by exchange merges. There are 4 nodes joining topology.
> When nodes 3 and 4 join at the same time, exchanges for [3, 0] and [4, 0] are
> merged. But, TopologyListener in service processor is notified about topVer
> [3, 0], for which there is no affinity because exchange has already moved
> forward to [4, 0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
[
https://issues.apache.org/jira/browse/IGNITE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540149#comment-16540149
]
Maxim Muzafarov commented on IGNITE-8905:
-
[~sergey-chugunov],
Make sense. Changes looks good to me.
Can you clarify: {{CacheSerializableTransactionsTest#testIncrementTxRestart}} –
I see fails on TC but can't reprcoduce error locally. What should I tune?
> Incorrect assertion in GridDhtPartitionsExchangeFuture
> --
>
> Key: IGNITE-8905
> URL: https://issues.apache.org/jira/browse/IGNITE-8905
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.7
>
> Original Estimate: 2h
> Time Spent: 2h
> Remaining Estimate: 59m
>
> Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture
> which is correct only in situation when client has to reconnect due to too
> short EXCHANGE_HISTORY.
> Exceptions from other situations like not being able to acquire file lock are
> also passed to client node in FullMessage.
> This assertion should be removed and check should be introduced instead: if
> this exception is intended to be thrown on current client node, we should do
> this, otherwise old program flow should be executed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8912) PartitionLossPolicy.READ_ONLY_SAFE does not detect partition loss
[ https://issues.apache.org/jira/browse/IGNITE-8912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540150#comment-16540150 ] Pavel Vinokurov commented on IGNITE-8912: - [~agoncharuk] TC results look good. > PartitionLossPolicy.READ_ONLY_SAFE does not detect partition loss > -- > > Key: IGNITE-8912 > URL: https://issues.apache.org/jira/browse/IGNITE-8912 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Attachments: MissedPartitionLostReproducer.java > > > Cluster of 4 for a cache with 1 backup and READ_ONLY_SAFE . > After forcefully killed two nodes, a partition lost without including in > partitionsLost collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8942) In some cases grid cannot be deactivated because of hanging CQ internal cleanup.
[
https://issues.apache.org/jira/browse/IGNITE-8942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540147#comment-16540147
]
ASF GitHub Bot commented on IGNITE-8942:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4329
> In some cases grid cannot be deactivated because of hanging CQ internal
> cleanup.
>
>
> Key: IGNITE-8942
> URL: https://issues.apache.org/jira/browse/IGNITE-8942
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.7
>
> Attachments: thread_dump_eip-server_2018-07-05-18-02.log
>
>
> See the attachment for thread dump.
> Most probably caused by blocking of message worker while waiting for cluster
> state change:
> {noformat}
> "tcp-disco-msg-worker-#2%DPL_GRID%DplGridNodeName%" #380 daemon prio=10
> os_prio=0 tid=0x7fe084c4c000 nid=0x39aa waiting on condition
> [0x7fdcd76f5000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:193)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.CacheMetricsImpl.isValidForOperation(CacheMetricsImpl.java:715)
> at
> org.apache.ignite.internal.processors.cache.CacheMetricsImpl.isValidForReading(CacheMetricsImpl.java:724)
> at
> org.apache.ignite.internal.processors.cache.CacheMetricsSnapshot.(CacheMetricsSnapshot.java:334)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.localMetrics(GridCacheAdapter.java:3255)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1098)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMetricsUpdateMessage(ServerImpl.java:5141)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2794)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2570)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:6903)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2657)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:6847)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> Another problem:
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor#onDeActivate
> is called during exchange before transactions have completed, having
> probability of losing CQ updates for current transactions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8983) .NET long-running suite fails in master
[
https://issues.apache.org/jira/browse/IGNITE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-8983:
-
Description:
One of the following changes triggered the fails:
{code}
IGNITE-8681 Using ExpiryPolicy with persistence causes significant slowdown -
Fixes #4285.
IGNITE-7149 : Gradient boosting for decision tree
IGNITE-8746 EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the
coordinator IGNITE-8821 Reduced amount of logs for BPlusTreeSelfTest
put/remove family tests - Fixes #4218.
IGNITE-8203 Handle ClosedByInterruptionException in FilePageStore - Fixes
#4211.
IGNITE-8857 new IgnitePredicate filtering credential attribute
{code}
> .NET long-running suite fails in master
> ---
>
> Key: IGNITE-8983
> URL: https://issues.apache.org/jira/browse/IGNITE-8983
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.6
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.7
>
>
> One of the following changes triggered the fails:
> {code}
> IGNITE-8681 Using ExpiryPolicy with persistence causes significant slowdown
> - Fixes #4285.
> IGNITE-7149 : Gradient boosting for decision tree
> IGNITE-8746 EVT_CACHE_REBALANCE_PART_DATA_LOST event received twice on the
> coordinator IGNITE-8821 Reduced amount of logs for BPlusTreeSelfTest
> put/remove family tests - Fixes #4218.
> IGNITE-8203 Handle ClosedByInterruptionException in FilePageStore - Fixes
> #4211.
> IGNITE-8857 new IgnitePredicate filtering credential attribute
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8983) .NET long-running suite fails in master
Alexey Goncharuk created IGNITE-8983: Summary: .NET long-running suite fails in master Key: IGNITE-8983 URL: https://issues.apache.org/jira/browse/IGNITE-8983 Project: Ignite Issue Type: Test Affects Versions: 2.6 Reporter: Alexey Goncharuk Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7366) Affinity assignment exception in service processor during multiple nodes join
[
https://issues.apache.org/jira/browse/IGNITE-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-7366:
-
Fix Version/s: 2.7
> Affinity assignment exception in service processor during multiple nodes join
> -
>
> Key: IGNITE-7366
> URL: https://issues.apache.org/jira/browse/IGNITE-7366
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.7
>
>
> When two nodes which are deploying services join at the same time, and
> exception is observed:
> {code}
> SEVERE: Error when executing service: null
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=245d4bec-0384-4808-b66d-d2340930207f..., discPort=37500, order=2,
> intOrder=2, lastExchangeTime=1515394551283, loc=true,
> ver=2.3.0#20171028-sha1:8add7fd5, isClient=false], grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0],
> head=AffinityTopologyVersion [topVer=4, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=2, minorTopVer=0],
> AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion
> [topVer=4, minorTopVer=0]]]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:514)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:419)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:220)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:256)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:247)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:271)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1771)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1958)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> This may be caused by exchange merges. There are 4 nodes joining topology.
> When nodes 3 and 4 join at the same time, exchanges for [3, 0] and [4, 0] are
> merged. But, TopologyListener in service processor is notified about topVer
> [3, 0], for which there is no affinity because exchange has already moved
> forward to [4, 0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7366) Affinity assignment exception in service processor during multiple nodes join
[
https://issues.apache.org/jira/browse/IGNITE-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540098#comment-16540098
]
Ivan Daschinskiy commented on IGNITE-7366:
--
Guys, I suppose that this patch is good. I've merged it with recent master,
corrected some remarks from Pavel Kovalenko. Please, look at this ticket again.
> Affinity assignment exception in service processor during multiple nodes join
> -
>
> Key: IGNITE-7366
> URL: https://issues.apache.org/jira/browse/IGNITE-7366
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Pereslegin
>Priority: Major
>
> When two nodes which are deploying services join at the same time, and
> exception is observed:
> {code}
> SEVERE: Error when executing service: null
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=245d4bec-0384-4808-b66d-d2340930207f..., discPort=37500, order=2,
> intOrder=2, lastExchangeTime=1515394551283, loc=true,
> ver=2.3.0#20171028-sha1:8add7fd5, isClient=false], grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0],
> head=AffinityTopologyVersion [topVer=4, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=2, minorTopVer=0],
> AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion
> [topVer=4, minorTopVer=0]]]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:514)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:419)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:220)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:256)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:247)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:271)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1771)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1958)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> This may be caused by exchange merges. There are 4 nodes joining topology.
> When nodes 3 and 4 join at the same time, exchanges for [3, 0] and [4, 0] are
> merged. But, TopologyListener in service processor is notified about topVer
> [3, 0], for which there is no affinity because exchange has already moved
> forward to [4, 0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4841) Improve TEXT Query Documentation
[
https://issues.apache.org/jira/browse/IGNITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540094#comment-16540094
]
Vincent Free commented on IGNITE-4841:
--
The current lucene version does not allow ranges for integer values, upgrading
to a newer version will greatly improve the power of textQuery
> Improve TEXT Query Documentation
>
>
> Key: IGNITE-4841
> URL: https://issues.apache.org/jira/browse/IGNITE-4841
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 1.9
>Reporter: Daniel Siviter
>Priority: Major
>
> The documentation for Full TEXT Queries is thin at best:
> * What syntax does it use?
> * ...is it the full [Lucene Classic Query Parser
> Syntax|https://lucene.apache.org/core/6_3_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html]?
> * ...if so how does the syntax map to the {{@QueryTextField}} annotation?
> * How is Lucene analyser customisation performed?
> * What version is supported? (looks like 3.5.0 which is pretty old, latest is
> 6.4.1)
> * The
> [{{@QueryTextField}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/annotations/QueryTextField.html]
> JavaDoc refers to
> [{{CacheQuery}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/internal/processors/cache/query/CacheQuery.html]
> but strangely this doesn't even appear in the official JavaDoc. It is
> because it's an 'internal' class?
> It's mentioned multiple times as a feature, but doesn't look like much of
> Lucene can actually be utilised so clarifications would help greatly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8981) [ML] Parallel optimizations for BaggingTrainer
[ https://issues.apache.org/jira/browse/IGNITE-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540083#comment-16540083 ] ASF GitHub Bot commented on IGNITE-8981: GitHub user avplatonov opened a pull request: https://github.com/apache/ignite/pull/4350 IGNITE-8981: Parallel optimizations for BaggingTrainer add Learning environment with Logger and Parallelism strategy while learning You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8981 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4350.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 #4350 commit da3d2e91b11bbfb41346996e5358af2e917d08cb Author: Alexey Platonov Date: 2018-07-09T08:14:50Z initial commit commit 28682d61d0fcb68b3dda76a0631ba0d52e3907e0 Author: Alexey Platonov Date: 2018-07-09T09:49:14Z console logger and some refactorings commit 3eae7fa1bf0fd5b41e78537fd5a2559dd64c40ed Author: Alexey Platonov Date: 2018-07-09T10:19:49Z add examples, add Serializable i-face to LearningEnvironment commit 517e7d98f2004da5f1edd312980e2866c54584fa Author: Alexey Platonov Date: 2018-07-09T14:58:28Z Add comments commit bc82cfc74c99da43bca8993e48edc77aa78e45d3 Author: Alexey Platonov Date: 2018-07-10T08:45:42Z use enum instead of directly parallelism strategy passing commit d1d239ba0de3db1900b836e7a27377fad31e3f1a Author: Alexey Platonov Date: 2018-07-10T10:34:12Z use tracer while vector logging commit a9b851325a94634fce7373c06c5ea3596fa7cc18 Author: Alexey Platonov Date: 2018-07-10T11:42:50Z use toString method of model instead formatter while logging commit fff6eff8a5c00e497e9abce8c8e36ab75711abb8 Author: Alexey Platonov Date: 2018-07-11T10:13:44Z implement toString in models commit 8511d847b481233fa2438f5cce4b17e027e8b53b Author: Alexey Platonov Date: 2018-07-11T10:16:18Z pretty formatting in logging commit dc4fa77d5912a30f9749af125c571d66f470d8df Author: Alexey Platonov Date: 2018-07-11T10:45:21Z Merge branch 'master' of https://github.com/apache/ignite into ml/learning_environment_prototype commit e199ac9693cc9385bdcc75865eb49b985109f32f Author: Alexey Platonov Date: 2018-07-11T11:11:49Z format code according to coding style commit c19cacd43f7646e926dc8bf42cdb0e12d2811b43 Author: Alexey Platonov Date: 2018-07-11T13:04:42Z remove Serializable commit 4443160212053f64d3153986cec6ffd8473b48ad Author: Alexey Platonov Date: 2018-07-11T13:13:42Z remove useless condig > [ML] Parallel optimizations for BaggingTrainer > --- > > Key: IGNITE-8981 > URL: https://issues.apache.org/jira/browse/IGNITE-8981 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > > We could improve performance of BaggingTrainer using parallel optimizations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8982) SQL TX: reuse H2 connections
Ivan Pavlukhin created IGNITE-8982: -- Summary: SQL TX: reuse H2 connections Key: IGNITE-8982 URL: https://issues.apache.org/jira/browse/IGNITE-8982 Project: Ignite Issue Type: Improvement Reporter: Ivan Pavlukhin H2 Connection creation is not very fast. Reusing already created connections could speed up execution in several cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540078#comment-16540078
]
Anton Kalashnikov commented on IGNITE-8957:
---
[~andmed], I reviewed your changes and I have a question. Actually I have
question to original task. Are we really need to print all segments? I mean,
now we printing all of segments between this checkpoint and previous
checkpoint, also we print nothing if they contained in one segment. But I think
that printing number of segment for current checkpoint is enough for resolved
original problem. In any case, even printing only first and last segments
instead of printing all segments will be enough because segments are continuous.
I talked about it with [~agoncharuk](author of original task) and he is agree
about my proposal.
Any way, if you will decide not to change anything, can you check your solution
when two checkpoints in one segment.
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8981) [ML] Parallel optimizations for BaggingTrainer
Yury Babak created IGNITE-8981: -- Summary: [ML] Parallel optimizations for BaggingTrainer Key: IGNITE-8981 URL: https://issues.apache.org/jira/browse/IGNITE-8981 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Assignee: Alexey Platonov Fix For: 2.7 We could improve performance of BaggingTrainer using parallel optimizations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8922) Discovery message delivery guarantee can be violated
[
https://issues.apache.org/jira/browse/IGNITE-8922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540020#comment-16540020
]
ASF GitHub Bot commented on IGNITE-8922:
GitHub user dmekhanikov opened a pull request:
https://github.com/apache/ignite/pull/4349
IGNITE-8922 Fix delivery of pending messages
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8922
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4349.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 #4349
commit d08c808c4766cfc7538a8fdffe4bcf9b014bfe30
Author: Denis Mekhanikov
Date: 2018-07-04T08:44:02Z
IGNITE-8922 add tests for pending messages delivery
commit fcd100f9da4d6ff3f86971d9988c0cb5ea963603
Author: Denis Mekhanikov
Date: 2018-07-06T12:46:53Z
IGNITE-8922 check all ensured messages in test
commit aea7d9b2e10aaf641daa5e1a74d3d289239e063f
Author: Denis Mekhanikov
Date: 2018-07-11T08:56:07Z
IGNITE-8922 add custom messages to pending list in singleton cluster
commit 3325960fa98d12deac5c1d2a275fefd37c80b871
Author: Denis Mekhanikov
Date: 2018-07-11T10:04:40Z
IGNITE-8922 don't drop undiscarded messages from PendingMessages
commit b90687577d7f1b030c2609c6b0bb002b285616f0
Author: Denis Mekhanikov
Date: 2018-07-11T10:45:20Z
IGNITE-8922 add assertion messages to tests
> Discovery message delivery guarantee can be violated
>
>
> Key: IGNITE-8922
> URL: https://issues.apache.org/jira/browse/IGNITE-8922
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Critical
> Attachments: PendingMessageResendTest.java
>
>
> Under certain circumstances discovery messages may be delivered only to a
> part of nodes.
> It happens because pending messages are not resent due to data inconsistency
> in {{ServerImpl#PendingMessages}} class. If {{discardId}} or
> {{customDiscardId}} point to a message, that is not present in the queue,
> then other messages will be skipped and won't be resent. It may happen, for
> example, when queue in {{PendingMessages}} is overflown.
> PFA test, that reproduces this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8526) Create web-agent docker image for k8s deployment
[ https://issues.apache.org/jira/browse/IGNITE-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539972#comment-16539972 ] ASF GitHub Bot commented on IGNITE-8526: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4038 > 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 > Fix For: 2.7 > > 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-8942) In some cases grid cannot be deactivated because of hanging CQ internal cleanup.
[
https://issues.apache.org/jira/browse/IGNITE-8942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539968#comment-16539968
]
Sergey Chugunov commented on IGNITE-8942:
-
[~ascherbakov],
Change looks good, please go ahead and merge it.
However it doesn't fix the root cause of the issue but provides only a
workaround IMHO.
The issue is that code collecting cache metrics synchronously waits for
transition state instead of returning immediately.
*publicApiActiveState* method has a parameter *waitForTransition* which is
assigned to true in attached stack trace.
We may create a ticket of Minor priority to figure out how to implement the
correct fix: *waitForTransition* should be assigned to false when collecting
cache metrics. After that everything should be good.
> In some cases grid cannot be deactivated because of hanging CQ internal
> cleanup.
>
>
> Key: IGNITE-8942
> URL: https://issues.apache.org/jira/browse/IGNITE-8942
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.7
>
> Attachments: thread_dump_eip-server_2018-07-05-18-02.log
>
>
> See the attachment for thread dump.
> Most probably caused by blocking of message worker while waiting for cluster
> state change:
> {noformat}
> "tcp-disco-msg-worker-#2%DPL_GRID%DplGridNodeName%" #380 daemon prio=10
> os_prio=0 tid=0x7fe084c4c000 nid=0x39aa waiting on condition
> [0x7fdcd76f5000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:193)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.CacheMetricsImpl.isValidForOperation(CacheMetricsImpl.java:715)
> at
> org.apache.ignite.internal.processors.cache.CacheMetricsImpl.isValidForReading(CacheMetricsImpl.java:724)
> at
> org.apache.ignite.internal.processors.cache.CacheMetricsSnapshot.(CacheMetricsSnapshot.java:334)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.localMetrics(GridCacheAdapter.java:3255)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1098)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMetricsUpdateMessage(ServerImpl.java:5141)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2794)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2570)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:6903)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2657)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:6847)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> Another problem:
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor#onDeActivate
> is called during exchange before transactions have completed, having
> probability of losing CQ updates for current transactions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches
[ https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539929#comment-16539929 ] Dmitriy Pavlov commented on IGNITE-3303: [~avinogradov] [~dmagda] could you advice expert here? [~avinogradov] it seems you've already started review, so it would be great if you would have opportunity to finish. > Apache Flink Integration - Flink source to run a continuous query against one > or multiple caches > > > Key: IGNITE-3303 > URL: https://issues.apache.org/jira/browse/IGNITE-3303 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Saikat Maitra >Priority: Major > Attachments: Screen Shot 2016-10-07 at 12.44.47 AM.png, > testFlinkIgniteSourceWithLargeBatch.log, win7.PNG > > > Apache Flink integration > +++ *Ignite as a bidirectional Connector* +++ > As a Flink source => run a continuous query against one or multiple > caches [4]. > Related discussion : > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches
[ https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539919#comment-16539919 ] Anton Vinogradov commented on IGNITE-3303: -- [~samaitra], Currently I have no opportunity to make a review. [~dpavlov], Could you please find the reviewer? > Apache Flink Integration - Flink source to run a continuous query against one > or multiple caches > > > Key: IGNITE-3303 > URL: https://issues.apache.org/jira/browse/IGNITE-3303 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Saikat Maitra >Priority: Major > Attachments: Screen Shot 2016-10-07 at 12.44.47 AM.png, > testFlinkIgniteSourceWithLargeBatch.log, win7.PNG > > > Apache Flink integration > +++ *Ignite as a bidirectional Connector* +++ > As a Flink source => run a continuous query against one or multiple > caches [4]. > Related discussion : > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8912) PartitionLossPolicy.READ_ONLY_SAFE does not detect partition loss
[ https://issues.apache.org/jira/browse/IGNITE-8912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539890#comment-16539890 ] Alexey Goncharuk commented on IGNITE-8912: -- Looks good to me given that TC passes. > PartitionLossPolicy.READ_ONLY_SAFE does not detect partition loss > -- > > Key: IGNITE-8912 > URL: https://issues.apache.org/jira/browse/IGNITE-8912 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Attachments: MissedPartitionLostReproducer.java > > > Cluster of 4 for a cache with 1 backup and READ_ONLY_SAFE . > After forcefully killed two nodes, a partition lost without including in > partitionsLost collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8980) Web console: regression on Queries screen
[ https://issues.apache.org/jira/browse/IGNITE-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8980: --- Description: check box is too small !screenshot-1.png! > Web console: regression on Queries screen > - > > Key: IGNITE-8980 > URL: https://issues.apache.org/jira/browse/IGNITE-8980 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Dmitriy Shabalin >Priority: Major > Attachments: screenshot-1.png > > > check box is too small > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8980) Web console: regression on Queries screen
Pavel Konstantinov created IGNITE-8980: -- Summary: Web console: regression on Queries screen Key: IGNITE-8980 URL: https://issues.apache.org/jira/browse/IGNITE-8980 Project: Ignite Issue Type: Bug Components: wizards Reporter: Pavel Konstantinov Assignee: Dmitriy Shabalin Attachments: screenshot-1.png -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8980) Web console: regression on Queries screen
[ https://issues.apache.org/jira/browse/IGNITE-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-8980: --- Attachment: screenshot-1.png > Web console: regression on Queries screen > - > > Key: IGNITE-8980 > URL: https://issues.apache.org/jira/browse/IGNITE-8980 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Dmitriy Shabalin >Priority: Major > Attachments: screenshot-1.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8905) Incorrect assertion in GridDhtPartitionsExchangeFuture
[ https://issues.apache.org/jira/browse/IGNITE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539857#comment-16539857 ] Anton Kalashnikov commented on IGNITE-8905: --- Looks good for me. We need to wait TC run and if it's ok, this branch can be merged. > Incorrect assertion in GridDhtPartitionsExchangeFuture > -- > > Key: IGNITE-8905 > URL: https://issues.apache.org/jira/browse/IGNITE-8905 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > Original Estimate: 2h > Time Spent: 2h > Remaining Estimate: 59m > > Assertion was added as part IGNITE-8657 into GridDhtPartitionsExchangeFuture > which is correct only in situation when client has to reconnect due to too > short EXCHANGE_HISTORY. > Exceptions from other situations like not being able to acquire file lock are > also passed to client node in FullMessage. > This assertion should be removed and check should be introduced instead: if > this exception is intended to be thrown on current client node, we should do > this, otherwise old program flow should be executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8526) Create web-agent docker image for k8s deployment
[ https://issues.apache.org/jira/browse/IGNITE-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-8526. -- > 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 > Fix For: 2.7 > > 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-8971) GridRestProcessor should propagate error message
[ https://issues.apache.org/jira/browse/IGNITE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539837#comment-16539837 ] Alexey Kuznetsov commented on IGNITE-8971: -- [~andmed], you also need to modify "modules/web-console/frontend/app/services/Messages.service.js" logic that extract error message. You can ask [~vsisko] for assistance. > GridRestProcessor should propagate error message > > > Key: IGNITE-8971 > URL: https://issues.apache.org/jira/browse/IGNITE-8971 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Andrew Medvedev >Priority: Major > > GridRestProcessor should propagate error message (stack trace) for handling > disk full error messages -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8564) DataStreamer fails if client reconnected to the cluster and allowOverride = true
[ https://issues.apache.org/jira/browse/IGNITE-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539822#comment-16539822 ] Vyacheslav Koptilin commented on IGNITE-8564: - Hi [~ilyak] changes look good to me. > DataStreamer fails if client reconnected to the cluster and allowOverride = > true > > > Key: IGNITE-8564 > URL: https://issues.apache.org/jira/browse/IGNITE-8564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: test > Fix For: 2.7 > > Attachments: DataStreamerClientReconnectAfterClusterRestartTest.java > > > But wait, there's more. > This only happens when client has reconnected to a new cluster and topology > version after that is exactly the same like when it left. > Please see the attached test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539742#comment-16539742 ] Ilya Borisov edited comment on IGNITE-8958 at 7/11/18 8:51 AM: --- [~pkonstantinov] please test everything for regressions. The only thing I stumbled upon was a single E2E test regression, which I fixed (also fixes IGNITE-8094). [~anovikov] please review. was (Author: klaster_1): [~pkonstantinov] please test everything for regressions. The only thing I stumbled upon was a single E2E test regression, which I fixed. [~anovikov] please review. > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Original Estimate: 48h > Time Spent: 4h > Remaining Estimate: 44h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539742#comment-16539742 ] Ilya Borisov edited comment on IGNITE-8958 at 7/11/18 8:50 AM: --- [~pkonstantinov] please test everything for regressions. The only thing I stumbled upon was a single E2E test regression, which I fixed. [~anovikov] please review. was (Author: klaster_1): [~pkonstantinov] please test everything for regressions. [~anovikov] please review. > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Original Estimate: 48h > Time Spent: 1h > Remaining Estimate: 47h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8958) Web console: upgrade to AngularJS 1.7
[ https://issues.apache.org/jira/browse/IGNITE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8958: Assignee: Pavel Konstantinov (was: Ilya Borisov) [~pkonstantinov] please test everything for regressions. [~anovikov] please review. > Web console: upgrade to AngularJS 1.7 > - > > Key: IGNITE-8958 > URL: https://issues.apache.org/jira/browse/IGNITE-8958 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Original Estimate: 48h > Time Spent: 1h > Remaining Estimate: 47h > > AngularJS 1.7 provides more features that will improve migration to Angular, > so let's update and fix any issues that will probably occur along the way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8979) Web console: Unable to choose the item by the mouse in 'Refresh rate' dropdown in the Query
[ https://issues.apache.org/jira/browse/IGNITE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8979: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good. Merged to master. > Web console: Unable to choose the item by the mouse in 'Refresh rate' > dropdown in the Query > --- > > Key: IGNITE-8979 > URL: https://issues.apache.org/jira/browse/IGNITE-8979 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > Attachments: image-2018-07-11-15-21-02-606.png > > > Open Query screen. > Click on the 'Refresh rate' button and try to select another measurement by > the mouse. > !image-2018-07-11-15-21-02-606.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8979) Web console: Unable to choose the item by the mouse in 'Refresh rate' dropdown in the Query
[ https://issues.apache.org/jira/browse/IGNITE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8979: - Fix Version/s: 2.7 > Web console: Unable to choose the item by the mouse in 'Refresh rate' > dropdown in the Query > --- > > Key: IGNITE-8979 > URL: https://issues.apache.org/jira/browse/IGNITE-8979 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: image-2018-07-11-15-21-02-606.png > > > Open Query screen. > Click on the 'Refresh rate' button and try to select another measurement by > the mouse. > !image-2018-07-11-15-21-02-606.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8979) Web console: Unable to choose the item by the mouse in 'Refresh rate' dropdown in the Query
[ https://issues.apache.org/jira/browse/IGNITE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8979: - Component/s: wizards > Web console: Unable to choose the item by the mouse in 'Refresh rate' > dropdown in the Query > --- > > Key: IGNITE-8979 > URL: https://issues.apache.org/jira/browse/IGNITE-8979 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: image-2018-07-11-15-21-02-606.png > > > Open Query screen. > Click on the 'Refresh rate' button and try to select another measurement by > the mouse. > !image-2018-07-11-15-21-02-606.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8912) PartitionLossPolicy.READ_ONLY_SAFE does not detect partition loss
[ https://issues.apache.org/jira/browse/IGNITE-8912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539719#comment-16539719 ] Pavel Vinokurov commented on IGNITE-8912: - [~agoncharuk] Please review > PartitionLossPolicy.READ_ONLY_SAFE does not detect partition loss > -- > > Key: IGNITE-8912 > URL: https://issues.apache.org/jira/browse/IGNITE-8912 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > Attachments: MissedPartitionLostReproducer.java > > > Cluster of 4 for a cache with 1 backup and READ_ONLY_SAFE . > After forcefully killed two nodes, a partition lost without including in > partitionsLost collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8979) Web console: Unable to choose the item by the mouse in 'Refresh rate' dropdown in the Query
Pavel Konstantinov created IGNITE-8979: -- Summary: Web console: Unable to choose the item by the mouse in 'Refresh rate' dropdown in the Query Key: IGNITE-8979 URL: https://issues.apache.org/jira/browse/IGNITE-8979 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov Attachments: image-2018-07-11-15-21-02-606.png Open Query screen. Click on the 'Refresh rate' button and try to select another measurement by the mouse. !image-2018-07-11-15-21-02-606.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539617#comment-16539617
]
Maxim Muzafarov commented on IGNITE-8957:
-
[~andmed],
Thankk you, looks much better.
Let's run all suites on TC to be sure that we will cover all test cases by this
fix and will have no new failures.
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8873) Optimize cache scans with enabled persistence.
[ https://issues.apache.org/jira/browse/IGNITE-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-8873: - Assignee: Vladislav Pyatkov > Optimize cache scans with enabled persistence. > -- > > Key: IGNITE-8873 > URL: https://issues.apache.org/jira/browse/IGNITE-8873 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.7 > > > Currently cache scans with enabled persistence involve link resolution, which > can lead to radom disk access resulting in bad performace on SAS disks. > One possibility is to preload cache data pages to remove slow random disk > access. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
