[jira] [Commented] (IGNITE-11969) Incorrect DefaultConcurrencyLevel value in .net test
[ https://issues.apache.org/jira/browse/IGNITE-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881565#comment-16881565 ] Dmitriy Govorukhin commented on IGNITE-11969: - [~akalashnikov] LGTM, merged to master. > Incorrect DefaultConcurrencyLevel value in .net test > > > Key: IGNITE-11969 > URL: https://issues.apache.org/jira/browse/IGNITE-11969 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Incorrect DefaultConcurrencyLevel value in .net test after default > configuration in java was changed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11969) Incorrect DefaultConcurrencyLevel value in .net test
[
https://issues.apache.org/jira/browse/IGNITE-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881559#comment-16881559
]
Ignite TC Bot commented on IGNITE-11969:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4298206buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect DefaultConcurrencyLevel value in .net test
>
>
> Key: IGNITE-11969
> URL: https://issues.apache.org/jira/browse/IGNITE-11969
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Incorrect DefaultConcurrencyLevel value in .net test after default
> configuration in java was changed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8717) Move persisted cache configuration to metastore and introduce cache configuration versioning
[ https://issues.apache.org/jira/browse/IGNITE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881515#comment-16881515 ] Eduard Shangareev commented on IGNITE-8717: --- Any updates here? Is it in progress yet? > Move persisted cache configuration to metastore and introduce cache > configuration versioning > > > Key: IGNITE-8717 > URL: https://issues.apache.org/jira/browse/IGNITE-8717 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Sergey Antonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we persist cache configuration to local files which resulted in > several inconsistencies when a node misses configuration update (create > index, cache destroy, etc). > I think the cache configuration should be saved to the metastore the same way > as baseline topology is saved. Same mechanics should be used for conflicting > configuration updates resolution. > Along with cache configuration, it also makes sense to move marshaller and > binary metadata to the metastore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7822) SQL Query with union and left join produces "Column not found" error
[ https://issues.apache.org/jira/browse/IGNITE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881426#comment-16881426 ] Ilya Kasnacheev commented on IGNITE-7822: - Minimal reproducer as follows: create table a (id int primary key, name varchar); create table aa (id int primary key, a_id int); create table ab (id int primary key, a_id int); select ab.id from (select id, name from a where id = 1 union select id, name from a where id = 2) a left join aa on a.id = aa.a_id left join ab on a.id = ab.a_id; > SQL Query with union and left join produces "Column not found" error > > > Key: IGNITE-7822 > URL: https://issues.apache.org/jira/browse/IGNITE-7822 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1, 2.3 >Reporter: Pavel Vinokurov >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Initial script: > > CREATE TABLE Person (id INTEGER PRIMARY KEY, company_id INTEGER, salary > DECIMAL); > CREATE TABLE Company (id INTEGER PRIMARY KEY, name VARCHAR); > CREATE TABLE Company_Value (id INTEGER PRIMARY KEY, company_id INTEGER, > market_value DECIMAL); > INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), > (3, 3, 300); > INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3'); > INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, > 1), (2, 2, 2), (3, 3, 3); > CREATE TABLE Address (id INTEGER PRIMARY KEY, person_id INTEGER, city > VARCHAR); > > Query: > SELECT a.id FROM (SELECT p1.id as pid, p1.salary, p1.company_id > FROM Person p1 WHERE p1.id = 1 UNION SELECT p2.id as pid, > p2.salary, p2.company_id FROM Person p2 WHERE p2.id = 2) p LEFT > JOIN Company c ON p.company_id = c.id LEFT JOIN Company_Value cv ON c.id = > cv.company_id LEFT JOIN Address a ON a.person_id = p.pid; > > Result: > Exception:Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z2.ID" not > found; SQL statement:SELECTC__Z3.ID __C2_0FROM PUBLIC.COMPANY C__Z3 LEFT > OUTER JOIN PUBLIC.COMPANY_VALUE CV__Z4 ON C__Z3.ID = CV__Z4.COMPANY_ID LEFT > OUTER JOIN PUBLIC.ADDRESS A__Z5 ON A__Z5.PERSON_ID = P__Z2.IDORDER BY 1 > [42122-195] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7822) SQL Query with union and left join produces "Column not found" error
[ https://issues.apache.org/jira/browse/IGNITE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-7822: --- Assignee: Ilya Kasnacheev > SQL Query with union and left join produces "Column not found" error > > > Key: IGNITE-7822 > URL: https://issues.apache.org/jira/browse/IGNITE-7822 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1, 2.3 >Reporter: Pavel Vinokurov >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Initial script: > > CREATE TABLE Person (id INTEGER PRIMARY KEY, company_id INTEGER, salary > DECIMAL); > CREATE TABLE Company (id INTEGER PRIMARY KEY, name VARCHAR); > CREATE TABLE Company_Value (id INTEGER PRIMARY KEY, company_id INTEGER, > market_value DECIMAL); > INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), > (3, 3, 300); > INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3'); > INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, > 1), (2, 2, 2), (3, 3, 3); > CREATE TABLE Address (id INTEGER PRIMARY KEY, person_id INTEGER, city > VARCHAR); > > Query: > SELECT a.id FROM (SELECT p1.id as pid, p1.salary, p1.company_id > FROM Person p1 WHERE p1.id = 1 UNION SELECT p2.id as pid, > p2.salary, p2.company_id FROM Person p2 WHERE p2.id = 2) p LEFT > JOIN Company c ON p.company_id = c.id LEFT JOIN Company_Value cv ON c.id = > cv.company_id LEFT JOIN Address a ON a.person_id = p.pid; > > Result: > Exception:Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z2.ID" not > found; SQL statement:SELECTC__Z3.ID __C2_0FROM PUBLIC.COMPANY C__Z3 LEFT > OUTER JOIN PUBLIC.COMPANY_VALUE CV__Z4 ON C__Z3.ID = CV__Z4.COMPANY_ID LEFT > OUTER JOIN PUBLIC.ADDRESS A__Z5 ON A__Z5.PERSON_ID = P__Z2.IDORDER BY 1 > [42122-195] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7822) SQL Query with union and left join produces "Column not found" error
[ https://issues.apache.org/jira/browse/IGNITE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-7822: Description: Initial script: CREATE TABLE Person (id INTEGER PRIMARY KEY, company_id INTEGER, salary DECIMAL); CREATE TABLE Company (id INTEGER PRIMARY KEY, name VARCHAR); CREATE TABLE Company_Value (id INTEGER PRIMARY KEY, company_id INTEGER, market_value DECIMAL); INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), (3, 3, 300); INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3'); INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, 1), (2, 2, 2), (3, 3, 3); CREATE TABLE Address (id INTEGER PRIMARY KEY, person_id INTEGER, city VARCHAR); Query: SELECT a.id FROM (SELECT p1.id as pid, p1.salary, p1.company_id FROM Person p1 WHERE p1.id = 1 UNION SELECT p2.id as pid, p2.salary, p2.company_id FROM Person p2 WHERE p2.id = 2) p LEFT JOIN Company c ON p.company_id = c.id LEFT JOIN Company_Value cv ON c.id = cv.company_id LEFT JOIN Address a ON a.person_id = p.pid; Result: Exception:Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z2.ID" not found; SQL statement:SELECTC__Z3.ID __C2_0FROM PUBLIC.COMPANY C__Z3 LEFT OUTER JOIN PUBLIC.COMPANY_VALUE CV__Z4 ON C__Z3.ID = CV__Z4.COMPANY_ID LEFT OUTER JOIN PUBLIC.ADDRESS A__Z5 ON A__Z5.PERSON_ID = P__Z2.IDORDER BY 1 [42122-195] was: Initial script: CREATE TABLE Person (id INTEGER PRIMARY KEY, company_id INTEGER, salary DECIMAL); CREATE TABLE Company (id INTEGER PRIMARY KEY, name VARCHAR); CREATE TABLE Company_Value (id INTEGER PRIMARY KEY, company_id INTEGER, market_value DECIMAL); INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), (3, 3, 300); INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3'); INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, 1), (2, 2, 2), (3, 3, 3); CREATE TABLE Address (id INTEGER PRIMARY KEY, person_id INTEGER, city VARCHAR);INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), (3, 3, 300);INSERT INTO Address (id, person_id, city) VALUES (1, 1, 'san francisco'), (2, 2, 'paris'), (3, 3, 'new york');INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3');INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, 1), (2, 2, 2), (3, 3, 3); Query: SELECT a.idFROM (SELECT p1.id as pid, p1.salary, p1.company_id FROM Person p1 WHERE p1.id = 1 UNION SELECT p2.id as pid, p2.salary, p2.company_id FROM Person p2 WHERE p2.id = 2) p LEFT JOIN Company c ON p.company_id = c.id LEFT JOIN Company_Value cv ON c.id = cv.company_id LEFT JOIN Address a ON a.person_id = p.pid; Result: Exception:Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z2.ID" not found; SQL statement:SELECTC__Z3.ID __C2_0FROM PUBLIC.COMPANY C__Z3 LEFT OUTER JOIN PUBLIC.COMPANY_VALUE CV__Z4 ON C__Z3.ID = CV__Z4.COMPANY_ID LEFT OUTER JOIN PUBLIC.ADDRESS A__Z5 ON A__Z5.PERSON_ID = P__Z2.IDORDER BY 1 [42122-195] > SQL Query with union and left join produces "Column not found" error > > > Key: IGNITE-7822 > URL: https://issues.apache.org/jira/browse/IGNITE-7822 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1, 2.3 >Reporter: Pavel Vinokurov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Initial script: > > CREATE TABLE Person (id INTEGER PRIMARY KEY, company_id INTEGER, salary > DECIMAL); > CREATE TABLE Company (id INTEGER PRIMARY KEY, name VARCHAR); > CREATE TABLE Company_Value (id INTEGER PRIMARY KEY, company_id INTEGER, > market_value DECIMAL); > INSERT INTO Person (id, company_id, salary) VALUES (1, 1, 100), (2, 2, 200), > (3, 3, 300); > INSERT INTO Company (id, name) VALUES (1, 'n1'), (2, 'n2'), (3, 'n3'); > INSERT INTO Company_Value (id, company_id, market_value) VALUES (1, 1, > 1), (2, 2, 2), (3, 3, 3); > CREATE TABLE Address (id INTEGER PRIMARY KEY, person_id INTEGER, city > VARCHAR); > > Query: > SELECT a.id FROM (SELECT p1.id as pid, p1.salary, p1.company_id > FROM Person p1 WHERE p1.id = 1 UNION SELECT p2.id as pid, > p2.salary, p2.company_id FROM Person p2 WHERE p2.id = 2) p LEFT > JOIN Company c ON p.company_id = c.id LEFT JOIN Company_Value cv ON c.id = > cv.company_id LEFT JOIN Address a ON a.person_id = p.pid; > > Result: > Exception:Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z2.ID" not > found; SQL statement:SELECTC__Z3.ID __C2_0FROM PUBLIC.COMPANY C__Z3 LEFT > OUTER JOIN PUBLIC.COMPANY_VALUE CV__Z4 ON C__Z3.ID = CV__Z4.COMPANY_ID LEFT
[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881322#comment-16881322 ] Ivan Fedotov commented on IGNITE-10973: --- [~Pavlukhin], I checked all blockers on TC bot. Apart from .Net block, the reason for all other blockers is "History for base branch is absent". Moreover, I made an experiment with @UseTechnicalNames annotation (look on the last two commits [1]) - it does not help, the name for TC still does not correspond to the previous name. So, from TC bot clear that all test from TC marked as blockers because of different name in parentheses and this is the only problem with naming. [1] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-711) [Java 8 Examples] Need to complete implementation of Java 8 examples.
[ https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881244#comment-16881244 ] Ivan Fedotov commented on IGNITE-711: - [~Pavlukhin], thank you. I resolved them in the last commit. > [Java 8 Examples] Need to complete implementation of Java 8 examples. > - > > Key: IGNITE-711 > URL: https://issues.apache.org/jira/browse/IGNITE-711 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Ivan Fedotov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Time Spent: 0.5h > Remaining Estimate: 0h > > There are next examples for java 7, but there are no for java 8. Need to > implement if they are applicable for java 8. > // BasicExamplesSelfTest > - ComputeReducerExample > - ComputeTaskMapExample > - ComputeTaskSplitExample > // CacheExamplesSelfTest: > - IgniteAtomicLongExample.main > - IgniteAtomicReferenceExample.main > - IgniteAtomicSequenceExample.main > - IgniteAtomicStampedExample.main > - IgniteCountDownLatchExample.main > - IgniteQueueExample.main > - IgniteSetExample.main > - CacheDummyStoreExample.main > - CacheQueryExample.main > - CacheTransactionExample.main > - CacheDataStreamerExample.main > - CachePutGetExample.main > - CacheStarSchemaExample.main > - CacheContinuousQueryExample.main > // CheckpointExamplesSelfTest > - ComputeFailoverExample > // ClusterGroupExampleSelfTest > - ClusterGroupExample > // ContinuationExamplesSelfTest > - ComputeFibonacciContinuationExample > // ContinuousMapperExamplesSelfTest > - ComputeContinuousMapperExample > - DeploymentExamplesMultiNodeSelfTest # testDeploymentExample > - DeploymentExamplesSelfTest # testDeploymentExample > // HibernateL2CacheExampleSelfTest > - HibernateL2CacheExample > - IgfsExamplesSelfTest # testIgniteFsApiExample > // LifecycleExamplesSelfTest > - LifecycleExample > - look at MemcacheRestExamplesMultiNodeSelfTest > - MemcacheRestExample > - CreditRiskExample > - SpringBeanExample > - ComputeTaskSplitExample > - ComputeTaskMapExample > Examples should be implemented for java 8 or testing methods should be > removed if examples do not applicable for java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[
https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881229#comment-16881229
]
Roman Kondakov commented on IGNITE-11907:
-
[~Pavlukhin], patch looks good for me except two minors:
# Todo on {{IncompleteDeserializationException.java:22}}
# Misspelling in "registration" word {{StartRoutineDiscoveryMessage.java:34}}
> Registration of continuous query should fail if nodes don't have remote
> filter class
>
>
> Key: IGNITE-11907
> URL: https://issues.apache.org/jira/browse/IGNITE-11907
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Attachments:
> ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If one of data nodes doesn't have a remote filter class, then registration of
> continuous queries should fail with an exception. Currently nodes fail
> instead.
> Reproducer is attached:
> [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10502) Add a danger block into transactions documentation
[ https://issues.apache.org/jira/browse/IGNITE-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-10502: - Ignite Flags: (was: Docs Required) > Add a danger block into transactions documentation > -- > > Key: IGNITE-10502 > URL: https://issues.apache.org/jira/browse/IGNITE-10502 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.6 >Reporter: Roman Guseinov >Assignee: Ilya Kasnacheev >Priority: Major > Labels: documentation > Fix For: 2.7.5 > > > Currently, we can not safely use caches with CacheStore and caches without > this one inside the same transaction. Those types of caches have different > recovery methods and some topology changes can lead inconsistent data: > [https://issues.apache.org/jira/browse/IGNITE-10452|https://issues.apache.org/jira/browse/IGNITE-10452] > It should be mentioned in the documentation to avoid confusing the users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10502) Add a danger block into transactions documentation
[ https://issues.apache.org/jira/browse/IGNITE-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-10502: - Fix Version/s: 2.7.5 > Add a danger block into transactions documentation > -- > > Key: IGNITE-10502 > URL: https://issues.apache.org/jira/browse/IGNITE-10502 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.6 >Reporter: Roman Guseinov >Assignee: Ilya Kasnacheev >Priority: Major > Labels: documentation > Fix For: 2.7.5 > > > Currently, we can not safely use caches with CacheStore and caches without > this one inside the same transaction. Those types of caches have different > recovery methods and some topology changes can lead inconsistent data: > [https://issues.apache.org/jira/browse/IGNITE-10452|https://issues.apache.org/jira/browse/IGNITE-10452] > It should be mentioned in the documentation to avoid confusing the users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10502) Add a danger block into transactions documentation
[ https://issues.apache.org/jira/browse/IGNITE-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881186#comment-16881186 ] Ilya Kasnacheev commented on IGNITE-10502: -- I have added warnings to docs: https://apacheignite.readme.io/docs/transactions#section-two-phase-commit-2pc > Add a danger block into transactions documentation > -- > > Key: IGNITE-10502 > URL: https://issues.apache.org/jira/browse/IGNITE-10502 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.6 >Reporter: Roman Guseinov >Assignee: Ilya Kasnacheev >Priority: Major > Labels: documentation > > Currently, we can not safely use caches with CacheStore and caches without > this one inside the same transaction. Those types of caches have different > recovery methods and some topology changes can lead inconsistent data: > [https://issues.apache.org/jira/browse/IGNITE-10452|https://issues.apache.org/jira/browse/IGNITE-10452] > It should be mentioned in the documentation to avoid confusing the users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10502) Add a danger block into transactions documentation
[ https://issues.apache.org/jira/browse/IGNITE-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev resolved IGNITE-10502. -- Resolution: Fixed > Add a danger block into transactions documentation > -- > > Key: IGNITE-10502 > URL: https://issues.apache.org/jira/browse/IGNITE-10502 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.6 >Reporter: Roman Guseinov >Assignee: Ilya Kasnacheev >Priority: Major > Labels: documentation > Fix For: 2.7.5 > > > Currently, we can not safely use caches with CacheStore and caches without > this one inside the same transaction. Those types of caches have different > recovery methods and some topology changes can lead inconsistent data: > [https://issues.apache.org/jira/browse/IGNITE-10452|https://issues.apache.org/jira/browse/IGNITE-10452] > It should be mentioned in the documentation to avoid confusing the users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-711) [Java 8 Examples] Need to complete implementation of Java 8 examples.
[ https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881163#comment-16881163 ] Ivan Pavlukhin commented on IGNITE-711: --- [~ivanan.fed], I left a couple of comments on [GitHub|https://github.com/apache/ignite/pull/6672#pullrequestreview-259440315]. > [Java 8 Examples] Need to complete implementation of Java 8 examples. > - > > Key: IGNITE-711 > URL: https://issues.apache.org/jira/browse/IGNITE-711 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Ivan Fedotov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Time Spent: 0.5h > Remaining Estimate: 0h > > There are next examples for java 7, but there are no for java 8. Need to > implement if they are applicable for java 8. > // BasicExamplesSelfTest > - ComputeReducerExample > - ComputeTaskMapExample > - ComputeTaskSplitExample > // CacheExamplesSelfTest: > - IgniteAtomicLongExample.main > - IgniteAtomicReferenceExample.main > - IgniteAtomicSequenceExample.main > - IgniteAtomicStampedExample.main > - IgniteCountDownLatchExample.main > - IgniteQueueExample.main > - IgniteSetExample.main > - CacheDummyStoreExample.main > - CacheQueryExample.main > - CacheTransactionExample.main > - CacheDataStreamerExample.main > - CachePutGetExample.main > - CacheStarSchemaExample.main > - CacheContinuousQueryExample.main > // CheckpointExamplesSelfTest > - ComputeFailoverExample > // ClusterGroupExampleSelfTest > - ClusterGroupExample > // ContinuationExamplesSelfTest > - ComputeFibonacciContinuationExample > // ContinuousMapperExamplesSelfTest > - ComputeContinuousMapperExample > - DeploymentExamplesMultiNodeSelfTest # testDeploymentExample > - DeploymentExamplesSelfTest # testDeploymentExample > // HibernateL2CacheExampleSelfTest > - HibernateL2CacheExample > - IgfsExamplesSelfTest # testIgniteFsApiExample > // LifecycleExamplesSelfTest > - LifecycleExample > - look at MemcacheRestExamplesMultiNodeSelfTest > - MemcacheRestExample > - CreditRiskExample > - SpringBeanExample > - ComputeTaskSplitExample > - ComputeTaskMapExample > Examples should be implemented for java 8 or testing methods should be > removed if examples do not applicable for java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11927) [IEP-35] Add ability to configure subset of metrics
[ https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881161#comment-16881161 ] Andrey Gura commented on IGNITE-11927: -- IMHO, histograms and hit rates configuration isn't related with metrics enabling/disabling and it should be done as separate units of work. > [IEP-35] Add ability to configure subset of metrics > --- > > Key: IGNITE-11927 > URL: https://issues.apache.org/jira/browse/IGNITE-11927 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Time Spent: 10m > Remaining Estimate: 0h > > Ignite should be able to: > * Enable or disable an arbitrary subset of the metrics. User should be able > to do it in runtime. > * Configure Histogram metrics > * Configure HitRate metrics. > We should provide 2 ways to configure metric: > 1. -Configuration file.- Discussed on dev-list. Agreed to go with the > simplest solution - JMX method. > 2. JMX method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881153#comment-16881153
]
Andrey Gura commented on IGNITE-7883:
-
[~a-polyakov] Could you please rebase your changes on the top of the master
branch and rerun TC? Your changes were made too long ago.
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11925) [IEP-35] Migrage QueryMetrics
[
https://issues.apache.org/jira/browse/IGNITE-11925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881136#comment-16881136
]
Ignite TC Bot commented on IGNITE-11925:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4296284buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-35] Migrage QueryMetrics
> -
>
> Key: IGNITE-11925
> URL: https://issues.apache.org/jira/browse/IGNITE-11925
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After merging of IGNITE-11848 we should migrate `QueryMetrics` to the new
> metric framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11967) control.sh validate_indexes SQL Index issue must contain information about cache group
[
https://issues.apache.org/jira/browse/IGNITE-11967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881130#comment-16881130
]
Sergey Antonov commented on IGNITE-11967:
-
[~ktkale...@gridgain.com] Changes looks good for me!
> control.sh validate_indexes SQL Index issue must contain information about
> cache group
> --
>
> Key: IGNITE-11967
> URL: https://issues.apache.org/jira/browse/IGNITE-11967
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment we have the following output in case of SQL index problems:
> {noformat}
> SQL Index [cache=union-module, idx=_key_PK] ValidateIndexesPartitionResult
> [consistentId=0.0.0.0:47500, sqlIdxName=_key_PK]
> IndexValidationIssue [key=0, cacheName=union-module, idxName=_key_PK], class
> org.apache.ignite.IgniteCheckedException: Key is present in SQL index, but
> can't be found in CacheDataTree.
> IndexValidationIssue [key=0, cacheName=union-module, idxName=_key_PK], class
> org.apache.ignite.IgniteCheckedException: Key is present in SQL index, but
> can't be found in CacheDataTree.
> IndexValidationIssue [key=null, cacheName=union-module, idxName=_key_PK],
> class java.lang.AssertionError: itemId=9, directCnt=9, indirectCnt=0,
> page=000133230112 [3883, 3669, 3456, 3242, 3029, 2815, 2602, 2386,
> 1747][][free=2101]
> IndexValidationIssue [key=0, cacheName=union-module, idxName=_key_PK], class
> org.apache.ignite.IgniteCheckedException: Key is present in SQL index, but
> can't be found in CacheDataTree.
> {noformat}
> We print info about cache name only. We should print information about cache
> group too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11970) Excessive use of memory in continuous queries
Igor Belyakov created IGNITE-11970: -- Summary: Excessive use of memory in continuous queries Key: IGNITE-11970 URL: https://issues.apache.org/jira/browse/IGNITE-11970 Project: Ignite Issue Type: Bug Reporter: Igor Belyakov When we prepare to send an entry into the continuous query's filter and listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. The batch is an array of entries of size IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the currently received entries (we need it for the case of concurrent updates to make sure that we preserve the order of update counters). The issue is that when we process a part of the array we keep the links to the processed entries until we exhaust the array (after when we finally clear it). Because of that we may store up to 999 garbage objects which can be a lot if the entries are big. Need to clear the entries right after we've processed them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11923) [IEP-35] Migrate IgniteMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov reassigned IGNITE-11923: - Assignee: Ivan Fedotov > [IEP-35] Migrate IgniteMXBean > - > > Key: IGNITE-11923 > URL: https://issues.apache.org/jira/browse/IGNITE-11923 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Ivan Fedotov >Priority: Major > Labels: IEP-35 > > After merging of IGNITE-11848 we should migrate `IgniteMXBean` to the new > metric framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11927) [IEP-35] Add ability to configure subset of metrics
[ https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-11927: Assignee: Nikolay Izhikov > [IEP-35] Add ability to configure subset of metrics > --- > > Key: IGNITE-11927 > URL: https://issues.apache.org/jira/browse/IGNITE-11927 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > Ignite should be able to: > * Enable or disable an arbitrary subset of the metrics. User should be able > to do it in runtime. > * Configure Histogram metrics > * Configure HitRate metrics. > We should provide 2 ways to configure metric: > 1. -Configuration file.- Discussed on dev-list. Agreed to go with the > simplest solution - JMX method. > 2. JMX method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11927) [IEP-35] Add ability to configure subset of metrics
[ https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11927: - Description: Ignite should be able to: * Enable or disable an arbitrary subset of the metrics. User should be able to do it in runtime. * Configure Histogram metrics * Configure HitRate metrics. We should provide 2 ways to configure metric: 1. -Configuration file.- Discussed on dev-list. Agreed to go with the simplest solution - JMX method. 2. JMX method. was: Ignite should be able to: * Enable or disable an arbitrary subset of the metrics. User should be able to do it in runtime. * Configure Histogram metrics * Configure HitRate metrics. We should provide 2 ways to configure metric: 1. ~Configuration file.~ Discussed on dev-list. Agreed to go with the simplest solution - JMX method. 2. JMX method. > [IEP-35] Add ability to configure subset of metrics > --- > > Key: IGNITE-11927 > URL: https://issues.apache.org/jira/browse/IGNITE-11927 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > Ignite should be able to: > * Enable or disable an arbitrary subset of the metrics. User should be able > to do it in runtime. > * Configure Histogram metrics > * Configure HitRate metrics. > We should provide 2 ways to configure metric: > 1. -Configuration file.- Discussed on dev-list. Agreed to go with the > simplest solution - JMX method. > 2. JMX method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11927) [IEP-35] Add ability to configure subset of metrics
[ https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11927: - Description: Ignite should be able to: * Enable or disable an arbitrary subset of the metrics. User should be able to do it in runtime. * Configure Histogram metrics * Configure HitRate metrics. We should provide 2 ways to configure metric: 1. ~Configuration file.~ Discussed on dev-list. Agreed to go with the simplest solution - JMX method. 2. JMX method. was: Ignite should be able to: * Enable or disable an arbitrary subset of the metrics. User should be able to do it in runtime. * Configure Histogram metrics * Configure HitRate metrics. We should provide 2 ways to configure metric: 1. Configuration file. 2. JMX method. > [IEP-35] Add ability to configure subset of metrics > --- > > Key: IGNITE-11927 > URL: https://issues.apache.org/jira/browse/IGNITE-11927 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > Ignite should be able to: > * Enable or disable an arbitrary subset of the metrics. User should be able > to do it in runtime. > * Configure Histogram metrics > * Configure HitRate metrics. > We should provide 2 ways to configure metric: > 1. ~Configuration file.~ Discussed on dev-list. Agreed to go with the > simplest solution - JMX method. > 2. JMX method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11969) Incorrect DefaultConcurrencyLevel value in .net test
[ https://issues.apache.org/jira/browse/IGNITE-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11969: Fix Version/s: 2.8 > Incorrect DefaultConcurrencyLevel value in .net test > > > Key: IGNITE-11969 > URL: https://issues.apache.org/jira/browse/IGNITE-11969 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Incorrect DefaultConcurrencyLevel value in .net test after default > configuration in java was changed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11969) Incorrect DefaultConcurrencyLevel value in .net test
[ https://issues.apache.org/jira/browse/IGNITE-11969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11969: Ignite Flags: (was: Docs Required) > Incorrect DefaultConcurrencyLevel value in .net test > > > Key: IGNITE-11969 > URL: https://issues.apache.org/jira/browse/IGNITE-11969 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Incorrect DefaultConcurrencyLevel value in .net test after default > configuration in java was changed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16880260#comment-16880260
]
Alexand Polyakov edited comment on IGNITE-7883 at 7/9/19 8:48 AM:
--
The code was tweaked, the tests passed. [~agura] please merge.
was (Author: a-polyakov):
[~agura] Fix remarks
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11969) Incorrect DefaultConcurrencyLevel value in .net test
Anton Kalashnikov created IGNITE-11969: -- Summary: Incorrect DefaultConcurrencyLevel value in .net test Key: IGNITE-11969 URL: https://issues.apache.org/jira/browse/IGNITE-11969 Project: Ignite Issue Type: Test Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Incorrect DefaultConcurrencyLevel value in .net test after default configuration in java was changed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11968) FailureProcessor reports tcp-comm-worker as blocked when resolving communication errors in ZK
[
https://issues.apache.org/jira/browse/IGNITE-11968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881038#comment-16881038
]
Stanislav Lukyanov commented on IGNITE-11968:
-
This may or may not be fixed by IGNITE-11865. Need to reproduce and verify the
fix.
> FailureProcessor reports tcp-comm-worker as blocked when resolving
> communication errors in ZK
> -
>
> Key: IGNITE-11968
> URL: https://issues.apache.org/jira/browse/IGNITE-11968
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> When multiple clients fail (stopped) at the same time and ZK discovery is
> used FailureProcessor treats tcp-comm-worker as blocked with the following
> trace:
> {code}
> Thread [name="tcp-comm-worker-#1", id=122, state=WAITING, blockCnt=1465,
> waitCnt=4557]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> o.a.i.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.resolveCommunicationError(ZookeeperDiscoveryImpl.java:359)
> at
> o.a.i.spi.discovery.zk.ZookeeperDiscoverySpi.resolveCommunicationFailure(ZookeeperDiscoverySpi.java:259)
> at
> o.a.i.i.managers.discovery.GridDiscoveryManager.resolveCommunicationError(GridDiscoveryManager.java:2549)
> at
> o.a.i.i.managers.GridManagerAdapter$1.resolveCommunicationFailure(GridManagerAdapter.java:626)
> at
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.processClientCreationError(TcpCommunicationSpi.java:3530)
> at
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3483)
> at
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2987)
> at
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2870)
> at
> o.a.i.spi.communication.tcp.TcpCommunicationSpi.access$6000(TcpCommunicationSpi.java:271)
> at
> o.a.i.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:4489)
> at
> o.a.i.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:4294)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
> at
> o.a.i.spi.communication.tcp.TcpCommunicationSpi$5.body(TcpCommunicationSpi.java:2237)
> at o.a.i.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11968) FailureProcessor reports tcp-comm-worker as blocked when resolving communication errors in ZK
Stanislav Lukyanov created IGNITE-11968:
---
Summary: FailureProcessor reports tcp-comm-worker as blocked when
resolving communication errors in ZK
Key: IGNITE-11968
URL: https://issues.apache.org/jira/browse/IGNITE-11968
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7
Reporter: Stanislav Lukyanov
When multiple clients fail (stopped) at the same time and ZK discovery is used
FailureProcessor treats tcp-comm-worker as blocked with the following trace:
{code}
Thread [name="tcp-comm-worker-#1", id=122, state=WAITING, blockCnt=1465,
waitCnt=4557]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
o.a.i.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.resolveCommunicationError(ZookeeperDiscoveryImpl.java:359)
at
o.a.i.spi.discovery.zk.ZookeeperDiscoverySpi.resolveCommunicationFailure(ZookeeperDiscoverySpi.java:259)
at
o.a.i.i.managers.discovery.GridDiscoveryManager.resolveCommunicationError(GridDiscoveryManager.java:2549)
at
o.a.i.i.managers.GridManagerAdapter$1.resolveCommunicationFailure(GridManagerAdapter.java:626)
at
o.a.i.spi.communication.tcp.TcpCommunicationSpi.processClientCreationError(TcpCommunicationSpi.java:3530)
at
o.a.i.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3483)
at
o.a.i.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2987)
at
o.a.i.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2870)
at
o.a.i.spi.communication.tcp.TcpCommunicationSpi.access$6000(TcpCommunicationSpi.java:271)
at
o.a.i.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:4489)
at
o.a.i.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:4294)
at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
at
o.a.i.spi.communication.tcp.TcpCommunicationSpi$5.body(TcpCommunicationSpi.java:2237)
at o.a.i.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
