[jira] [Commented] (IGNITE-8188) Batching operations should perform check for ZooKeeper request max size
[ https://issues.apache.org/jira/browse/IGNITE-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550275#comment-16550275 ] Amelchev Nikita commented on IGNITE-8188: - [~sergey-chugunov], Thank you. I have fixed it. Ran [TC tests|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F4236%2Fhead] again. Could you review? > Batching operations should perform check for ZooKeeper request max size > --- > > Key: IGNITE-8188 > URL: https://issues.apache.org/jira/browse/IGNITE-8188 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.7 > > > As ZooKeeper documentation > [says|https://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)] > batching *multi* operation has a limit for size of a single request. > ZookeeperClient batching methods *createAll* and *deleteAll* should check > this limit and fall back to execute operations one by one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8363) Handle topology changes during service deployment
[ https://issues.apache.org/jira/browse/IGNITE-8363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-8363: --- Fix Version/s: 2.7 > Handle topology changes during service deployment > - > > Key: IGNITE-8363 > URL: https://issues.apache.org/jira/browse/IGNITE-8363 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Denis Mekhanikov >Priority: Major > Labels: iep-17 > Fix For: 2.7 > > > Topology changes should be handled correctly during service deployment > process. > Assignments recalculation should be triggered when necessary. > Special attention should be paid to cases, when a coordinator or assigned > nodes fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8363) Handle topology changes during service deployment
[ https://issues.apache.org/jira/browse/IGNITE-8363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-8363: -- Assignee: Vyacheslav Daradur > Handle topology changes during service deployment > - > > Key: IGNITE-8363 > URL: https://issues.apache.org/jira/browse/IGNITE-8363 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.7 > > > Topology changes should be handled correctly during service deployment > process. > Assignments recalculation should be triggered when necessary. > Special attention should be paid to cases, when a coordinator or assigned > nodes fail. -- 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: Vasiliy Sisko (was: Ilya Borisov) I've rebased the branch to the latest master. > 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: Vasiliy Sisko >Priority: Minor > Attachments: ignite-8958-1.png > > Original Estimate: 48h > Time Spent: 4.5h > Remaining Estimate: 43.5h > > 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] [Commented] (IGNITE-9028) Web console: update to Babel 7
[ https://issues.apache.org/jira/browse/IGNITE-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550164#comment-16550164 ] Ilya Borisov commented on IGNITE-9028: -- [~anovikov], [~kuaw26] what do you think about an update to "unsupported browser" feature we added not so long ago, so it would [match|https://github.com/browserslist/browserslist-useragent] current browser agent against the same browserlist query used in .babelrc? This way we'd ensure there are no discrepancies between what's really supported and what's claimed to be supported. > Web console: update to Babel 7 > -- > > Key: IGNITE-9028 > URL: https://issues.apache.org/jira/browse/IGNITE-9028 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Major > > While Babel 7 is still in beta, I think it might be a good idea to update a > beta version of major dependency once in a while. It will be released soon > enough, so even if any issues occur we'll most like be able to iron those > out. As a benefit, Babel 7 will also provide an easy TypeScript migration > path. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9036) Update FasterXML jackson-databind dependency version in Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-9036: --- Flags: Important Fix Version/s: 2.7 > Update FasterXML jackson-databind dependency version in Apache Ignite > - > > Key: IGNITE-9036 > URL: https://issues.apache.org/jira/browse/IGNITE-9036 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Priority: Major > Fix For: 2.7 > > > Actual: jackson2.version in ignite parent pom is 2.6.5, required 2.9.5 or > later, > Latest version is 2.9.6 > affected modules will be at least ignite-aws. > It is required to run RunAll to check all tests passed, check full build > locally using build.sh. > Probably it is required to run release step to make sure release candidate > can be prepared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9036) Update FasterXML jackson-databind dependency version in Apache Ignite
Dmitriy Pavlov created IGNITE-9036: -- Summary: Update FasterXML jackson-databind dependency version in Apache Ignite Key: IGNITE-9036 URL: https://issues.apache.org/jira/browse/IGNITE-9036 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Pavlov Actual: jackson2.version in ignite parent pom is 2.6.5, required 2.9.5 or later, Latest version is 2.9.6 affected modules will be at least ignite-aws. It is required to run RunAll to check all tests passed, check full build locally using build.sh. Probably it is required to run release step to make sure release candidate can be prepared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9035) Update log4j 2x version in Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9035:
---
Issue Type: Improvement (was: Test)
> Update log4j 2x version in Apache Ignite
>
>
> Key: IGNITE-9035
> URL: https://issues.apache.org/jira/browse/IGNITE-9035
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.7
>
>
> It is suggested to update log4j 2x version to log4j 2.8.2 or later.
> {noformat}
>
> org.apache.logging.log4j
> log4j
> 2.8.2
> pom
>
> {noformat}
> It is required to run RunAll to check all tests passed.
> Probably it is required to run release step to make sure release candidate
> can be prepared.
> This will affect at least ignite-log4j2, ignite-spark and probably other
> modules.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9035) Update log4j 2x version in Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9035:
---
Description:
It is suggested to update log4j 2x version to log4j 2.8.2 or later.
{noformat}
org.apache.logging.log4j
log4j
2.8.2
pom
{noformat}
It is required to run RunAll to check all tests passed.
Probably it is required to run release step to make sure release candidate can
be prepared.
This will affect at least ignite-log4j2, ignite-spark and probably other
modules.
was:
It is suggested to update log4j 2x version to log4j 2.8.2 or later.
org.apache.logging.log4j
log4j
2.8.2
pom
It is required to run RunAll to check all tests passed.
Probably it is required to run release step to make sure release candidate can
be prepared.
> Update log4j 2x version in Apache Ignite
>
>
> Key: IGNITE-9035
> URL: https://issues.apache.org/jira/browse/IGNITE-9035
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.7
>
>
> It is suggested to update log4j 2x version to log4j 2.8.2 or later.
> {noformat}
>
> org.apache.logging.log4j
> log4j
> 2.8.2
> pom
>
> {noformat}
> It is required to run RunAll to check all tests passed.
> Probably it is required to run release step to make sure release candidate
> can be prepared.
> This will affect at least ignite-log4j2, ignite-spark and probably other
> modules.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9035) Update log4j 2x version in Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549641#comment-16549641
]
Dmitriy Pavlov commented on IGNITE-9035:
Probably we can update Ignite to latest version
{noformat}
org.apache.logging.log4j
log4j
2.11.0
pom
{noformat}
> Update log4j 2x version in Apache Ignite
>
>
> Key: IGNITE-9035
> URL: https://issues.apache.org/jira/browse/IGNITE-9035
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.7
>
>
> It is suggested to update log4j 2x version to log4j 2.8.2 or later.
>
> org.apache.logging.log4j
> log4j
> 2.8.2
> pom
>
> It is required to run RunAll to check all tests passed.
> Probably it is required to run release step to make sure release candidate
> can be prepared.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9035) Update log4j 2x version in Apache Ignite
Dmitriy Pavlov created IGNITE-9035: -- Summary: Update log4j 2x version in Apache Ignite Key: IGNITE-9035 URL: https://issues.apache.org/jira/browse/IGNITE-9035 Project: Ignite Issue Type: Test Reporter: Dmitriy Pavlov Fix For: 2.7 It is suggested to update log4j 2x version to log4j 2.8.2 or later. org.apache.logging.log4j log4j 2.8.2 pom It is required to run RunAll to check all tests passed. Probably it is required to run release step to make sure release candidate can be prepared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8973) Need to support dump for idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549600#comment-16549600
]
Anton Kalashnikov commented on IGNITE-8973:
---
https://reviews.ignite.apache.org/ignite/review/IGNT-CR-683
> Need to support dump for idle_verify
> -
>
> Key: IGNITE-8973
> URL: https://issues.apache.org/jira/browse/IGNITE-8973
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.7
>
>
> In a current implementation, idle_verify checking consistency between primary
> and backup partitions. Will be useful to have ability dump current state for
> all partition to file or standard output. This dump can help an investigation
> of some kind of problem with partition counters or sizes because it is a
> cluster partition hash snapshot by some partition state (hash include all
> keys in the partition).
> idle_verify --dump - calculate partition hash and print into standard output
> idle_verify --dump {path} - calculate partition hash and write output to file
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8220) Discovery worker termination in PDS test
[
https://issues.apache.org/jira/browse/IGNITE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549483#comment-16549483
]
ASF GitHub Bot commented on IGNITE-8220:
GitHub user EdShangGG opened a pull request:
https://github.com/apache/ignite/pull/4386
IGNITE-8220
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8220-1
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4386.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 #4386
commit fd9e66bfab07ab810e2e25aceeb64ef7c9f62d50
Author: EdShangGG
Date: 2018-07-19T15:32:52Z
IGNITE-8220 WIP
commit a876f48a6da3189332385e37f8cdf0028edd378f
Author: EdShangGG
Date: 2018-07-19T15:33:16Z
IGNITE-8220
> Discovery worker termination in PDS test
>
>
> Key: IGNITE-8220
> URL: https://issues.apache.org/jira/browse/IGNITE-8220
> Project: Ignite
> Issue Type: Test
> Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> 3 suites failed
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> Example of tests failed:
> - IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3
> - IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3
> {noformat}
> [2018-04-11
> 02:43:09,769][ERROR][tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%][IgniteTestResources]
> Critical failure. Will be handled accordingly to configured handler
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread
> tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%
> is terminated unexpectedly.]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9034) [ML] Add Estimator API support to TensorFlow cluster on top of Apache Ignite
Yury Babak created IGNITE-9034: -- Summary: [ML] Add Estimator API support to TensorFlow cluster on top of Apache Ignite Key: IGNITE-9034 URL: https://issues.apache.org/jira/browse/IGNITE-9034 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Assignee: Anton Dmitriev Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549465#comment-16549465 ] Dmitriy Sorokin commented on IGNITE-8719: - [~agoncharuk], I wrote the reproducer working by your scheme, but so far no confirmation for case when partially built index can be used. Look at my patch [#4380|https://github.com/apache/ignite/pull/4380], please, and tell me your opinion. > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Dmitriy Sorokin >Priority: Critical > Fix For: 2.7 > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7967) DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at runtime
[
https://issues.apache.org/jira/browse/IGNITE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549457#comment-16549457
]
Dmitriy Sorokin commented on IGNITE-7967:
-
[~agura], I modified my solution with your proposal so one it is more simple
now, review my new patch, please.
> DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at
> runtime
> ---
>
> Key: IGNITE-7967
> URL: https://issues.apache.org/jira/browse/IGNITE-7967
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: iep-6
> Fix For: 2.7
>
>
> {{totalAllocatedPages}} is updated during runtime via callback. When metrics
> are enabled at runtime, some pages may be already allocated, thus the metric
> shows invalid value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9031) SpringCacheManager throws AssertionError during Spring initialization
[
https://issues.apache.org/jira/browse/IGNITE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549421#comment-16549421
]
Joel Lang edited comment on IGNITE-9031 at 7/19/18 3:24 PM:
[~aakhmedov] you described the setup I have. Ignite is being started inside of
a host application which creates more than one {{ApplicationContext}}. This
isn't Spring MVC.
This host application first creates a {{FileSystemXmlApplicationContext}} using
root-app-context.xml, which imports ignite.xml.
Later it creates another {{ClassPathXmlApplicationContext}} using
extensions.xml which uses the previously created context as its parent. This is
the line in the stack trace when the assertion happens. This should be the root
cause.
I can post a stripped-down version of the root-app-context.xml and ignite.xml:
*root-app-context.xml:*
{code:xml}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd;>
cluster.properties
{code}
*ignite.xml:*
{code:xml}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:util="http://www.springframework.org/schema/util;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-4.3.xsd;>
{code}
was (Author: langj):
[~aakhmedov] you described the setup I have. Ignite is being started inside of
a host application which creates more than one {{ApplicationContext}}. This
isn't Spring MVC.
This host application first creates a {{FileSystemXmlApplicationContext}} using
root-app-context.xml, which imports ignite.xml.
Later it creates another {{ClassPathXmlApplicationContext}} using
extensions.xml which uses the previously created context as its parent. This is
the line in the stack trace when the assertion happens. This would be the root
cause.
I can post a stripped-down version of the root-app-context.xml and ignite.xml:
*root-app-context.xml:*
{code:xml}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd;>
cluster.properties
{code}
*ignite.xml:*
{code:xml}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:util="http://www.springframework.org/schema/util;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-4.3.xsd;>
{code}
> SpringCacheManager throws AssertionError during Spring initialization
> -
>
> Key: IGNITE-9031
> URL: https://issues.apache.org/jira/browse/IGNITE-9031
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.6
>Reporter: Joel Lang
>Assignee: Amir Akhmedov
>Priority: Major
>
> When initializing Ignite using an IgniteSpringBean and also having a
> SpringCacheManager defined, the SpringCacheManager throws an AssertionError
> in the onApplicationEvent() method due to it being called more than once.
> There is an "assert ignite == null" that fails after the first call.
> This is related to the changes in IGNITE-8740.
[jira] [Commented] (IGNITE-9031) SpringCacheManager throws AssertionError during Spring initialization
[
https://issues.apache.org/jira/browse/IGNITE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549421#comment-16549421
]
Joel Lang commented on IGNITE-9031:
---
[~aakhmedov] you described the setup I have. Ignite is being started inside of
a host application which creates more than one {{ApplicationContext}}. This
isn't Spring MVC.
This host application first creates a {{FileSystemXmlApplicationContext}} using
root-app-context.xml, which imports ignite.xml.
Later it creates another {{ClassPathXmlApplicationContext}} using
extensions.xml which uses the previously created context as its parent. This is
the line in the stack trace when the assertion happens. This would be the root
cause.
I can post a stripped-down version of the root-app-context.xml and ignite.xml:
*root-app-context.xml:*
{code:xml}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd;>
cluster.properties
{code}
*ignite.xml:*
{code:xml}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xmlns:util="http://www.springframework.org/schema/util;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-4.3.xsd;>
{code}
> SpringCacheManager throws AssertionError during Spring initialization
> -
>
> Key: IGNITE-9031
> URL: https://issues.apache.org/jira/browse/IGNITE-9031
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.6
>Reporter: Joel Lang
>Assignee: Amir Akhmedov
>Priority: Major
>
> When initializing Ignite using an IgniteSpringBean and also having a
> SpringCacheManager defined, the SpringCacheManager throws an AssertionError
> in the onApplicationEvent() method due to it being called more than once.
> There is an "assert ignite == null" that fails after the first call.
> This is related to the changes in IGNITE-8740. This happened immediately when
> I first tried to start Ignite after upgrading from 2.5 to 2.6.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8619) Remote node could not start in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8619: --- Description: Now there is a problem with launch remote node via ssh. Initially was an assumption that it's due to remote process has not enough time to write information into log: [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this correction didn't fix [TeamCity |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails] (IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls). So it's necessary to make launch remote node via ssh always succesful. was: Now there is a problem with launch remote node via ssh. Initially was an assumption that it's due to remote process has not enough time to write information into log: [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this correction didn't fix [TeamCity |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. So it's necessary to make launch remote node via ssh always succesful. > Remote node could not start in ssh connection > - > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails] > (IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls). > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8619) Remote node could not start in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8619: --- Labels: MakeTeamcityGreenAgain (was: ) > Remote node could not start in ssh connection > - > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. > > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8188) Batching operations should perform check for ZooKeeper request max size
[ https://issues.apache.org/jira/browse/IGNITE-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549342#comment-16549342 ] Sergey Chugunov commented on IGNITE-8188: - [~NSAmelchev], There are two more places in the code that create batches as ArrayLists, I left comments in UpSource review at both lines. Please fix them and we'll proceed with merging. > Batching operations should perform check for ZooKeeper request max size > --- > > Key: IGNITE-8188 > URL: https://issues.apache.org/jira/browse/IGNITE-8188 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.7 > > > As ZooKeeper documentation > [says|https://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)] > batching *multi* operation has a limit for size of a single request. > ZookeeperClient batching methods *createAll* and *deleteAll* should check > this limit and fall back to execute operations one by one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8860) IgniteDiscoveryThread marker interface should be restored on RingMessageWorker class
[ https://issues.apache.org/jira/browse/IGNITE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549330#comment-16549330 ] Sergey Chugunov commented on IGNITE-8860: - Original issue where this interface was added is IGNITE-6668. > IgniteDiscoveryThread marker interface should be restored on > RingMessageWorker class > > > Key: IGNITE-8860 > URL: https://issues.apache.org/jira/browse/IGNITE-8860 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Sergey Chugunov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.7 > > > It seems that *IgniteDiscoveryThread* interface was removed from > *ServerImpl.RingMessageWorker* class. > It should be restored as it is used to prevent deadlocks on updates of > BinaryMetadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-8860) IgniteDiscoveryThread marker interface should be restored on RingMessageWorker class
[ https://issues.apache.org/jira/browse/IGNITE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-8860: Comment: was deleted (was: Original issue where this interface was added is IGNITE-6668.) > IgniteDiscoveryThread marker interface should be restored on > RingMessageWorker class > > > Key: IGNITE-8860 > URL: https://issues.apache.org/jira/browse/IGNITE-8860 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Sergey Chugunov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.7 > > > It seems that *IgniteDiscoveryThread* interface was removed from > *ServerImpl.RingMessageWorker* class. > It should be restored as it is used to prevent deadlocks on updates of > BinaryMetadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8998) Client hangs after merge exchange
[ https://issues.apache.org/jira/browse/IGNITE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549298#comment-16549298 ] Anton Kalashnikov commented on IGNITE-8998: --- TC - https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=projectOverview_IgniteTests24Java8=pull%2F4358%2Fhead > Client hangs after merge exchange > - > > Key: IGNITE-8998 > URL: https://issues.apache.org/jira/browse/IGNITE-8998 > Project: Ignite > Issue Type: Test >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > > Reproduce by CacheExchangeMergeTest#testConcurrentStartServersAndClients -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8930) ODBC: Cursors are not closed when used through Go
[
https://issues.apache.org/jira/browse/IGNITE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-8930:
---
Assignee: Igor Sapego
> ODBC: Cursors are not closed when used through Go
> -
>
> Key: IGNITE-8930
> URL: https://issues.apache.org/jira/browse/IGNITE-8930
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.5
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.7
>
>
> Client used: https://github.com/alexbrainman/odbc
> Example app for reproducing:
> [https://github.com/nombiezinja/ignite-cursor-example]
> After several execution of statements user begins to get the following error:
> {noformat}
> 2018/06/29 20:46:06 SQLExecute: {HY000} Too many open cursors (either close
> other open cursors or increase the limit through
> ClientConnectorConfiguration.maxOpenCursorsPerConnection) [maximum=128,
> current=128]{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8495) CPP Thin: Implement thin client start and connection establishment
[ https://issues.apache.org/jira/browse/IGNITE-8495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549268#comment-16549268 ] ASF GitHub Bot commented on IGNITE-8495: Github user isapego closed the pull request at: https://github.com/apache/ignite/pull/4071 > CPP Thin: Implement thin client start and connection establishment > -- > > Key: IGNITE-8495 > URL: https://issues.apache.org/jira/browse/IGNITE-8495 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 2.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Need to implement basic functionality for C++ thin client - configuration, > starting, connection to server, handshake. -- 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=16549259#comment-16549259
]
ASF GitHub Bot commented on IGNITE-8922:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4349
> Discovery message delivery guarantee can be violated
>
>
> Key: IGNITE-8922
> URL: https://issues.apache.org/jira/browse/IGNITE-8922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Critical
> Fix For: 2.7
>
> 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] [Comment Edited] (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=16549254#comment-16549254
]
Dmitriy Pavlov edited comment on IGNITE-8922 at 7/19/18 1:13 PM:
-
I've checked TC tests run, it seems to be OK.
I've merged changes to master.
[~yzhdanov], [~dkarachentsev], thank you for review.
[~dmekhanikov], thank you for contribution.
was (Author: dpavlov):
I've checked TC tests run, it seems to be OK.
I've merged changes to master.
[~yzhdanov] thank you for review.
[~dmekhanikov], thank you for contribution.
> Discovery message delivery guarantee can be violated
>
>
> Key: IGNITE-8922
> URL: https://issues.apache.org/jira/browse/IGNITE-8922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Critical
> Fix For: 2.7
>
> 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-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549249#comment-16549249
]
Sergey Chugunov commented on IGNITE-8131:
-
[~garus.d.g],
I'm not sure if ZookeeperDiscoveryTestSuite2 has some tests for client
reconnects so I triggered [one
run|https://ci.ignite.apache.org/viewLog.html?buildId=1517979=queuedBuildOverviewTab].
If TC status is OK lets move the fix into main PR.
It looks good to me so I think we're getting closer to have it merged.
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: ZK_client_reconnect_failure.log,
> ZK_client_reconnect_success.log
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-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=16549234#comment-16549234
]
Yakov Zhdanov commented on IGNITE-8922:
---
Changes look good to me.
Thanks!
> Discovery message delivery guarantee can be violated
>
>
> Key: IGNITE-8922
> URL: https://issues.apache.org/jira/browse/IGNITE-8922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Critical
> Fix For: 2.7
>
> 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-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549223#comment-16549223
]
Denis Garus commented on IGNITE-8131:
-
[~sergey-chugunov]
I've done the fix by moving initializing evtsData earlier.
I've executed test 700 times local and everything looks to be OK.
[PR|https://github.com/apache/ignite/pull/4384]
[TC|https://ci.ignite.apache.org/viewLog.html?buildId=1517848=buildResultsDiv=IgniteTests24Java8_ZooKeeperDiscovery1]
Should I move this fix into the main PR?
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: ZK_client_reconnect_failure.log,
> ZK_client_reconnect_success.log
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9024) Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549219#comment-16549219 ] Eduard Shangareev commented on IGNITE-9024: --- Looks good. [~agura] could you merge PR? > Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest > - > > Key: IGNITE-9024 > URL: https://issues.apache.org/jira/browse/IGNITE-9024 > Project: Ignite > Issue Type: Test >Affects Versions: 2.5 >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > DynamicIndexAbstractConcurrentSelfTest has BlockingIndexing inplementation > which allows synchronize indexing operations with other concurrent routines. > Transition to waiting for unblock indexing state being notified from > awaitIndexing method by countDown() call on idxLatch, which should be > awaiting on test thread, but calls of countDown() method on idxLatch > instances are present in that code points too. > Replace of countDown() calls by await() calls on idxLatch instances is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8220) Discovery worker termination in PDS test
[
https://issues.apache.org/jira/browse/IGNITE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-8220:
-
Assignee: Eduard Shangareev (was: Alexey Goncharuk)
> Discovery worker termination in PDS test
>
>
> Key: IGNITE-8220
> URL: https://issues.apache.org/jira/browse/IGNITE-8220
> Project: Ignite
> Issue Type: Test
> Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> 3 suites failed
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> Example of tests failed:
> - IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3
> - IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3
> {noformat}
> [2018-04-11
> 02:43:09,769][ERROR][tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%][IgniteTestResources]
> Critical failure. Will be handled accordingly to configured handler
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread
> tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%
> is terminated unexpectedly.]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9033) .NET: specify expiry policy when creating cache using thin client
Igor Sapego created IGNITE-9033: --- Summary: .NET: specify expiry policy when creating cache using thin client Key: IGNITE-9033 URL: https://issues.apache.org/jira/browse/IGNITE-9033 Project: Ignite Issue Type: New Feature Components: platforms Reporter: Igor Sapego Need to add ability to create dynamic caches specifying expiry policy with thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9021) [ML] Refactor vectors to dence/sparse
[ https://issues.apache.org/jira/browse/IGNITE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549157#comment-16549157 ] ASF GitHub Bot commented on IGNITE-9021: GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/4385 IGNITE-9021 - Fixed tests - Leave classes used in MLP/DT/another algorithms only - Fixed code-style for many places You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9021 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4385.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 #4385 commit ca6a608bd6fff3a8e719ad475c0d662f38bf7f60 Author: Zinoviev Alexey Date: 2018-07-19T10:34:22Z IGNITE-9021: refactored impls and tests commit ea6f95655f957dc8ac97fed4157e395025bacd3c Author: Zinoviev Alexey Date: 2018-07-19T11:28:43Z IGNITE-9021: fixed code issues > [ML] Refactor vectors to dence/sparse > -- > > Key: IGNITE-9021 > URL: https://issues.apache.org/jira/browse/IGNITE-9021 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > > We want to remove all unused implementations of Vector interface. Same for > matrices. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9004) Failed to reinitialize local partitions
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549154#comment-16549154
]
ASF GitHub Bot commented on IGNITE-9004:
GitHub user EdShangGG opened a pull request:
https://github.com/apache/ignite/pull/4383
IGNITE-9004
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9004
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4383.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 #4383
commit c4ab6c9481d0b019434e65085c08f501a58259c8
Author: EdShangGG
Date: 2018-07-17T19:13:32Z
IGNITE-9004 WIP
commit 3229732dee496a22606504893681d2cec3f7dc93
Author: EdShangGG
Date: 2018-07-18T11:50:54Z
IGNITE-9004 WIP
commit 476de884606860599156b15b338c59353dc2a980
Author: EdShangGG
Date: 2018-07-18T16:23:47Z
IGNITE-9004 WIP
commit 3c1f0503c934dcafa475a21cc9f2859324e5978d
Author: EdShangGG
Date: 2018-07-18T19:00:49Z
IGNITE-9004 WIP
commit 3cd22b88c8569b9d9bd6efeafc217019df5d99ad
Author: Eduard Shangareev
Date: 2018-07-19T11:27:57Z
Revert "IGNITE-9004 WIP"
This reverts commit 3c1f050
> Failed to reinitialize local partitions
> ---
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, almost any tests in
> IgniteChangeGlobalStateTest class. for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
> reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
> initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
> branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
> forceChangeBaselineTopology=false, timestamp=1531832492029],
> affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.25.4.132], sockAddrs=[/172.25.4.132:47504,
> /0:0:0:0:0:0:0:1%lo:47504, /127.0.0.1:47504], discPort=47504, order=2,
> intOrder=2, lastExchangeTime=1531832486546, loc=false,
> ver=2.7.0#19700101-sha1:, isClient=false], topVer=6,
> nodeId8=9960f6b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
> tstamp=1531832492035]], nodeId=8dced5ba, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: calculatedOffset=3072, allocated=2048,
> headerSize=1024
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
> at
>
[jira] [Commented] (IGNITE-8183) ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
[
https://issues.apache.org/jira/browse/IGNITE-8183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549152#comment-16549152
]
ASF GitHub Bot commented on IGNITE-8183:
Github user dgarus closed the pull request at:
https://github.com/apache/ignite/pull/4382
> ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
> ---
>
> Key: IGNITE-8183
> URL: https://issues.apache.org/jira/browse/IGNITE-8183
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test fails with assertion on awaits on latch:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testSegmentation3(ZookeeperDiscoverySpiTest.java:1060)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason SEGMENTATION event is never fired, so assertion on latch
> fails. Investigation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[
https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549150#comment-16549150
]
Stanilovsky Evgeny edited comment on IGNITE-8719 at 7/19/18 11:25 AM:
--
also, index creation can be crashed independently, for example with Error
during parallel index create/rebuild.
{code:java}
IgniteChackedException: maximum of retries 1000 reached.
at
org.apache.ignite.internal.processors.cache.persistence.tree.BplusTree$Get.checkLockRetry(BPlusTree.java:2565)
{code}
was (Author: zstan):
also, index creation can be crashed independently, for example with Error
during parallel index create/rebuild.
IgniteChackedException: maximum of retries 1000 reached.
at
org.apache.ignite.internal.processors.cache.persistence.tree.BplusTree$Get.checkLockRetry(BPlusTree.java:2565)
> Index left partially built if a node crashes during index create or rebuild
> ---
>
> Key: IGNITE-8719
> URL: https://issues.apache.org/jira/browse/IGNITE-8719
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.7
>
>
> Currently, we do not have any state associated with the index tree. Consider
> the following scenario:
> 1) Start node, put some data
> 2) start CREATE INDEX operation
> 3) Wait for a checkpoint and stop node before index create finished
> 4) Restart node
> Since the checkpoint finished, the new index tree will be persisted to the
> disk, but not all data will be present in the index.
> We should somehow store information about initializing index tree and mark it
> valid only after all data is indexed. The state should be persisted as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549150#comment-16549150 ] Stanilovsky Evgeny commented on IGNITE-8719: also, index creation can be crashed independently, for example with Error during parallel index create/rebuild. IgniteChackedException: maximum of retries 1000 reached. at org.apache.ignite.internal.processors.cache.persistence.tree.BplusTree$Get.checkLockRetry(BPlusTree.java:2565) > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Dmitriy Sorokin >Priority: Critical > Fix For: 2.7 > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8183) ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
[
https://issues.apache.org/jira/browse/IGNITE-8183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549094#comment-16549094
]
ASF GitHub Bot commented on IGNITE-8183:
GitHub user dgarus opened a pull request:
https://github.com/apache/ignite/pull/4382
IGNITE-8183. fix 3
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dgarus/ignite ignte-8131_fix_3
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4382.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 #4382
commit eed42a68a27f4f2388df96c04136938817a54c5f
Author: Garus Denis
Date: 2018-07-19T10:28:28Z
IGNITE-8183. fix 3
> ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
> ---
>
> Key: IGNITE-8183
> URL: https://issues.apache.org/jira/browse/IGNITE-8183
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Test fails with assertion on awaits on latch:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testSegmentation3(ZookeeperDiscoverySpiTest.java:1060)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason SEGMENTATION event is never fired, so assertion on latch
> fails. Investigation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7823) Separate cache for non collocated IgniteSet.
[ https://issues.apache.org/jira/browse/IGNITE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549065#comment-16549065 ] Pavel Pereslegin commented on IGNITE-7823: -- Hello [~avinogradov], I merged with master and updated TC results. > Separate cache for non collocated IgniteSet. > > > Key: IGNITE-7823 > URL: https://issues.apache.org/jira/browse/IGNITE-7823 > Project: Ignite > Issue Type: New Feature > Components: data structures >Reporter: Andrey Kuznetsov >Assignee: Pavel Pereslegin >Priority: Major > Fix For: 2.7 > > > Currently, single data structures cache is shared between several collection > instances (IgniteQueue, IgniteSet). > To support iterator() and size() IgniteSet maintains plain on-heap Java sets > on every node (see CacheDataStructuresManager.setDataMap). These sets > duplicate backing-cache entries, both primary and backup. For big > non-collocated sets it's too expensive to maintain redundant onheap data > copies. The simplest way to avoid copies is to use separate cache for > non-collocated IgniteSet version; hence size of set is the same as size of > backing cache, and also set iterator is virtually the same as backing cache > iterator. > The difference between exising set implementation and set based on separate > cache should be properly documented afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8990) Web console: unexpected 'Unsaved changes' warning
[ https://issues.apache.org/jira/browse/IGNITE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549055#comment-16549055 ] Vasiliy Sisko commented on IGNITE-8990: --- Still reproduced with *client connector configuration* -> *enabled* flag. See ignite-8990.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: Vasiliy Sisko >Priority: Major > Attachments: ignite-8990.png, 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] [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 ] Vasiliy Sisko reassigned IGNITE-8990: - Assignee: Ilya Borisov (was: Vasiliy Sisko) > 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: ignite-8990.png, 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 ] Vasiliy Sisko updated IGNITE-8990: -- Attachment: ignite-8990.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: Vasiliy Sisko >Priority: Major > Attachments: ignite-8990.png, 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] [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: Ilya Borisov (was: Vasiliy Sisko) > 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: Ilya Borisov >Priority: Minor > Attachments: ignite-8958-1.png > > Original Estimate: 48h > Time Spent: 4.5h > Remaining Estimate: 43.5h > > 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] [Commented] (IGNITE-8188) Batching operations should perform check for ZooKeeper request max size
[ https://issues.apache.org/jira/browse/IGNITE-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548944#comment-16548944 ] Amelchev Nikita commented on IGNITE-8188: - [~sergey-chugunov], Thank for your comments. I have fixed PR and ran [tests on TC again|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F4236%2Fhead]. One test failed _ZookeeperDiscoverySpiTest.testCommunicationFailureResolve_CachesInfo1_ and it isn't my changes fail by the log. Local test run OK. Could you review? > Batching operations should perform check for ZooKeeper request max size > --- > > Key: IGNITE-8188 > URL: https://issues.apache.org/jira/browse/IGNITE-8188 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.7 > > > As ZooKeeper documentation > [says|https://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)] > batching *multi* operation has a limit for size of a single request. > ZookeeperClient batching methods *createAll* and *deleteAll* should check > this limit and fall back to execute operations one by one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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=16548936#comment-16548936 ] Vasiliy Sisko commented on IGNITE-8958: --- Tested. Dialog does not appear. > 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: Vasiliy Sisko >Priority: Minor > Attachments: ignite-8958-1.png > > Original Estimate: 48h > Time Spent: 4.5h > Remaining Estimate: 43.5h > > 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] [Commented] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes
[ https://issues.apache.org/jira/browse/IGNITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548866#comment-16548866 ] Stanilovsky Evgeny commented on IGNITE-584: --- [~EdShangGG] can u review ones more ? > Need to make sure that scan query returns consistent results on topology > changes > > > Key: IGNITE-584 > URL: https://issues.apache.org/jira/browse/IGNITE-584 > Project: Ignite > Issue Type: Sub-task > Components: data structures >Affects Versions: 1.9, 2.0, 2.1 >Reporter: Artem Shutak >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.7 > > Attachments: tc1.png > > > Consistent results on topology changes was implemented for sql queries, but > looks like it still does not work for scan queries. > This affects 'cache set' tests since set uses scan query for set iteration > (to be unmuted on TC): > GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and > testNodeJoinsAndLeavesCollocated; > Also see todos here GridCacheSetFailoverAbstractSelfTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
