[jira] [Updated] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10177:
Description:
If needed, refer parent task for more details.
# remove Junit3-specific parts of API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven (if there are any)
# migrate tests that were missed at prior steps, if there are any
## untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
which currently conflict with Junit4 execution because of using constructors
and make them properly use {{@Test}} annotation
## find out why
{{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
start running slow / timing out after adding Junit 4 annotations (reproduced
this on teamcity and locally as was discovered in IGNITE-10175)
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# find and update all Junit3-specific code that {{extends TestCase}}
# execute junit related inspections of IDE and analyse results
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
was:
If needed, refer parent task for more details.
# remove deprecated API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven
# migrate tests that were missed at prior steps, if there are any
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}} to
add the class via Junit4 adapter
# find and update all Junit3-specific code that {{extends TestCase}}
# untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass which
currently conflict with Junit4 execution because of using constructors and make
them properly use {{@Test}} annotation
# find out why
{{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
start running slow / timing out after adding Junit 4 annotations (reproduced
this on teamcity and locally as was discovered in IGNITE-10175)
# execute junit related inspections of IDE and analyse results
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove Junit3-specific parts of API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven (if there are any)
> # migrate tests that were missed at prior steps, if there are any
> ## untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> ## find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # find and update all Junit3-specific code that {{extends TestCase}}
> # execute junit related inspections of IDE and analyse results
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713879#comment-16713879
]
Oleg Ignatenko commented on IGNITE-10177:
-
plan in the description once had a bullet point about reviewing {{import
org.junit}} and possible removal. Upon closer study this turned a poor idea,
these should be left alone, primarily because importing asserts is done best
from {{org.junit.Assert}}
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove deprecated API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven
> # migrate tests that were missed at prior steps, if there are any
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}}
> to add the class via Junit4 adapter
> # find and update all Junit3-specific code that {{extends TestCase}}
> # untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> # find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> # execute junit related inspections of IDE and analyse results
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10177:
Description:
If needed, refer parent task for more details.
# remove deprecated API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven
# migrate tests that were missed at prior steps, if there are any
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}} to
add the class via Junit4 adapter
# find and update all Junit3-specific code that {{extends TestCase}}
# untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass which
currently conflict with Junit4 execution because of using constructors and make
them properly use {{@Test}} annotation
# find out why
{{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
start running slow / timing out after adding Junit 4 annotations (reproduced
this on teamcity and locally as was discovered in IGNITE-10175)
# execute junit related inspections of IDE and analyse results
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
was:
If needed, refer parent task for more details.
# remove deprecated API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven
# migrate tests that were missed at prior steps, if there are any
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}} to
add the class via Junit4 adapter
# find and update all Junit3-specific code that {{extends TestCase}}
# untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass which
currently conflict with Junit4 execution because of using constructors and make
them properly use {{@Test}} annotation
# find out why
{{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
start running slow / timing out after adding Junit 4 annotations (reproduced
this on teamcity and locally as was discovered in IGNITE-10175)
# review and if possible upgrade all occurrences of {{import org.junit}} in the
project
# execute junit related inspections of IDE and analyse results
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove deprecated API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven
> # migrate tests that were missed at prior steps, if there are any
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}}
> to add the class via Junit4 adapter
> # find and update all Junit3-specific code that {{extends TestCase}}
> # untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> # find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> # execute junit related inspections of IDE and analyse results
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
>
[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches
[ https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713814#comment-16713814 ] Saikat Maitra commented on IGNITE-3303: --- [~dpavlov] can you please review and merge this PR [https://github.com/apache/ignite/pull/5020] > Apache Flink Integration - Flink source to run a continuous query against one > or multiple caches > > > Key: IGNITE-3303 > URL: https://issues.apache.org/jira/browse/IGNITE-3303 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > Fix For: 2.8 > > Attachments: Screen Shot 2016-10-07 at 12.44.47 AM.png, > testFlinkIgniteSourceWithLargeBatch.log, win7.PNG > > > Apache Flink integration > +++ *Ignite as a bidirectional Connector* +++ > As a Flink source => run a continuous query against one or multiple > caches [4]. > Related discussion : > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10608) SpringDataExample fails with java.lang.AbstractMethodError
[
https://issues.apache.org/jira/browse/IGNITE-10608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kozlov updated IGNITE-10608:
---
Description:
Open example project in IDEA, compile and run {{SpringDataExample}}:
{noformat}
[23:18:34] Topology snapshot [ver=1, locNode=d4e3a93b, servers=1, clients=0,
state=ACTIVE, CPUs=4, offheap=4.8GB, heap=5.3GB]
[23:18:34] Ignite node stopped OK [name=springDataNode, uptime=00:00:00.120]
Exception in thread "main"
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'personRepository': Initialization of bean failed; nested exception
is java.lang.AbstractMethodError
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:742)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)
at
org.apache.ignite.examples.springdata.SpringDataExample.igniteSpringDataInit(SpringDataExample.java:79)
at
org.apache.ignite.examples.springdata.SpringDataExample.main(SpringDataExample.java:52)
Caused by: java.lang.AbstractMethodError
at
org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:99)
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:302)
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:129)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1537)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1284)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
... 10 more
{noformat}
was:
Open example prject in IDEA compile and run {{SpringDataExample}}:
{noformat}
[23:18:34] Topology snapshot [ver=1, locNode=d4e3a93b, servers=1, clients=0,
state=ACTIVE, CPUs=4, offheap=4.8GB, heap=5.3GB]
[23:18:34] Ignite node stopped OK [name=springDataNode, uptime=00:00:00.120]
Exception in thread "main"
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'personRepository': Initialization of bean failed; nested exception
is java.lang.AbstractMethodError
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:742)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)
at
org.apache.ignite.examples.springdata.SpringDataExample.igniteSpringDataInit(SpringDataExample.java:79)
at
org.apache.ignite.examples.springdata.SpringDataExample.main(SpringDataExample.java:52)
Caused by:
[jira] [Updated] (IGNITE-10608) SpringDataExample fails with java.lang.AbstractMethodError
[
https://issues.apache.org/jira/browse/IGNITE-10608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kozlov updated IGNITE-10608:
---
Ignite Flags: (was: Docs Required)
> SpringDataExample fails with java.lang.AbstractMethodError
> --
>
> Key: IGNITE-10608
> URL: https://issues.apache.org/jira/browse/IGNITE-10608
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Reporter: Sergey Kozlov
>Priority: Major
>
> Open example prject in IDEA compile and run {{SpringDataExample}}:
> {noformat}
> [23:18:34] Topology snapshot [ver=1, locNode=d4e3a93b, servers=1, clients=0,
> state=ACTIVE, CPUs=4, offheap=4.8GB, heap=5.3GB]
> [23:18:34] Ignite node stopped OK [name=springDataNode, uptime=00:00:00.120]
> Exception in thread "main"
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'personRepository': Initialization of bean failed; nested exception
> is java.lang.AbstractMethodError
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:742)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)
> at
> org.apache.ignite.examples.springdata.SpringDataExample.igniteSpringDataInit(SpringDataExample.java:79)
> at
> org.apache.ignite.examples.springdata.SpringDataExample.main(SpringDataExample.java:52)
> Caused by: java.lang.AbstractMethodError
> at
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:99)
> at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:302)
> at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:129)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1537)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1284)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10608) SpringDataExample fails with java.lang.AbstractMethodError
Sergey Kozlov created IGNITE-10608:
--
Summary: SpringDataExample fails with java.lang.AbstractMethodError
Key: IGNITE-10608
URL: https://issues.apache.org/jira/browse/IGNITE-10608
Project: Ignite
Issue Type: Bug
Components: examples
Reporter: Sergey Kozlov
Open example prject in IDEA compile and run {{SpringDataExample}}:
{noformat}
[23:18:34] Topology snapshot [ver=1, locNode=d4e3a93b, servers=1, clients=0,
state=ACTIVE, CPUs=4, offheap=4.8GB, heap=5.3GB]
[23:18:34] Ignite node stopped OK [name=springDataNode, uptime=00:00:00.120]
Exception in thread "main"
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'personRepository': Initialization of bean failed; nested exception
is java.lang.AbstractMethodError
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:742)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)
at
org.apache.ignite.examples.springdata.SpringDataExample.igniteSpringDataInit(SpringDataExample.java:79)
at
org.apache.ignite.examples.springdata.SpringDataExample.main(SpringDataExample.java:52)
Caused by: java.lang.AbstractMethodError
at
org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:99)
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:302)
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:129)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1537)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1284)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
... 10 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko reassigned IGNITE-10177:
---
Assignee: Oleg Ignatenko
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove deprecated API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven
> # migrate tests that were missed at prior steps, if there are any
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}}
> to add the class via Junit4 adapter
> # find and update all Junit3-specific code that {{extends TestCase}}
> # untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> # find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> # review and if possible upgrade all occurrences of {{import org.junit}} in
> the project
> # execute junit related inspections of IDE and analyse results
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10176) migrate non-core modules tests from Junit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713739#comment-16713739
]
Ignite TC Bot commented on IGNITE-10176:
{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=2490823buildTypeId=IgniteTests24Java8_RunAll]
> migrate non-core modules tests from Junit 3 to 4
>
>
> Key: IGNITE-10176
> URL: https://issues.apache.org/jira/browse/IGNITE-10176
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> Migrate using new API introduced and tested at prior step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10589) Multiple server node failure after a client node stopping
[
https://issues.apache.org/jira/browse/IGNITE-10589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713692#comment-16713692
]
Ignite TC Bot commented on IGNITE-10589:
{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=2492348buildTypeId=IgniteTests24Java8_RunAll]
> Multiple server node failure after a client node stopping
> -
>
> Key: IGNITE-10589
> URL: https://issues.apache.org/jira/browse/IGNITE-10589
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kosarev
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.8
>
> Attachments: 16_02.tar
>
>
> after stopping a client
> we see topology change and pme finish on the coordinator,
> and at soon on another nodes we still don't see new topology, but have
> Critical error resulting nodes failure
> crd log
> {code}
> 2018-12-06 15:55:23.660 [WARN
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Node FAILED: ZookeeperClusterNode [id=979f03db-f858-44f6-8646-12034dfd5c93,
> addrs=[10.116.206.1], order=129, loc=false, client=true]
> 2018-12-06 15:55:23.660 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Topology snapshot [ver=162, servers=128, clients=0, CPUs=7168,
> offheap=14.0GB, heap=4000.0GB]
> 2018-12-06 15:55:23.660 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- Node [id=44D27930-80E5-4EB7-B377-8B07C02C2033, clusterState=ACTIVE]
> 2018-12-06 15:55:23.660 [INFO
> ][zk-DPL_GRID%DplGridNodeName-EventThread][o.a.i.s.d.z.i.ZookeeperDiscoveryImpl]
> Process alive nodes change [alives=128]
> 2018-12-06 15:55:23.661 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- Baseline [id=0, size=128, online=128, offline=0]
> 2018-12-06 15:55:23.661 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Data Regions Configured:
> 2018-12-06 15:55:23.661 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- dpl_mem_plc [initSize=256.0 MiB, maxSize=556.6 GiB,
> persistenceEnabled=true]
> 2018-12-06 15:55:23.661 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- not-persisted [initSize=256.0 MiB, maxSize=556.6 GiB,
> persistenceEnabled=false]
> 2018-12-06 15:55:23.670
> [DEBUG][sys-#564%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.l.ExchangeLatchManager]
> Process node left 979f03db-f858-44f6-8646-12034dfd5c93
> 2018-12-06 15:55:23.670 [INFO
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.exchange.time]
> Started exchange init [topVer=AffinityTopologyVersion [topVer=162,
> minorTopVer=0], crd=true, evt=NODE_FAILED,
> evtNode=979f03db-f858-44f6-8646-12034dfd5c93, customEvt=null, allowMerge=true]
> 2018-12-06 15:55:23.712 [INFO
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.exchange.time]
> Finished exchange init [topVer=AffinityTopologyVersion [topVer=162,
> minorTopVer=0], crd=true]
> 2018-12-06 15:55:23.699 [INFO
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Finish exchange future [startVer=AffinityTopologyVersion [topVer=162,
> minorTopVer=0], resVer=AffinityTopologyVersion [topVer=162, minorTopVer=0],
> err=null]
> {code}
> on a node(1) we have critical error(1)
> {code}
> 2018-12-06 15:55:23.727
> [ERROR][utility-#432%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=1e17c56a-5213-4a1b-b94b-4575a95a2c81,
> msg=GridDhtTxPrepareRequest [nearNodeId=44d27930-80e5-4eb7-b377-8b07c02c2033,
> futId=1d225238761-05eea259-5c25-4a4b-8469-9dd8980e218c, miniId=105,
> topVer=AffinityTopologyVersion [topVer=162, minorTopVer=0],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=155571374, order=1545423626166, nodeOrd
> er=1], subjId=44d27930-80e5-4eb7-b377-8b07c02c2033, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=1281,
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
> [topVer=15557137
> 4, order=1545423626614, nodeOrder=96], timeout=0, reads=null,
> writes=ArrayList [IgniteTxEntry [key=KeyCacheObjectImpl [part=65,
> val=GridServiceAssignmentsKey [name=DPLThreadManager_service],
> hasValBytes=true], cacheId=-2100569601, txKey=IgniteTxKey [key=KeyCa
> cheObjectImpl [part=65, val=GridServiceAssignmentsKey
>
[jira] [Updated] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10177:
Description:
If needed, refer parent task for more details.
# remove deprecated API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven
# migrate tests that were missed at prior steps, if there are any
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}} to
add the class via Junit4 adapter
# find and update all Junit3-specific code that {{extends TestCase}}
# untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass which
currently conflict with Junit4 execution because of using constructors and make
them properly use {{@Test}} annotation
# find out why
{{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
start running slow / timing out after adding Junit 4 annotations (reproduced
this on teamcity and locally as was discovered in IGNITE-10175)
# review and if possible upgrade all occurrences of {{import org.junit}} in the
project
# execute junit related inspections of IDE and analyse results
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
was:
If needed, refer parent task for more details.
# remove deprecated API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven
# migrate tests that were missed at prior steps, if there are any
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}} to
add the class via Junit4 adapter
# find and update all Junit3-specific code that {{extends TestCase}}
# untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass which
currently conflict with Junit4 execution because of using constructors and make
them properly use {{@Test}} annotation
# review and if possible upgrade all occurrences of {{import org.junit}} in the
project
# execute junit related inspections of IDE and analyse results
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove deprecated API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven
> # migrate tests that were missed at prior steps, if there are any
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}}
> to add the class via Junit4 adapter
> # find and update all Junit3-specific code that {{extends TestCase}}
> # untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> # find out why
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} appears to
> start running slow / timing out after adding Junit 4 annotations (reproduced
> this on teamcity and locally as was discovered in IGNITE-10175)
> # review and if possible upgrade all occurrences of {{import org.junit}} in
> the project
> # execute junit related inspections of IDE and analyse results
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
>
[jira] [Commented] (IGNITE-10175) migrate core module tests from Junit 3 to 4
[ https://issues.apache.org/jira/browse/IGNITE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713684#comment-16713684 ] Oleg Ignatenko commented on IGNITE-10175: - [~dop] - last time I spoke to [~EdShangGG] he mentioned that you were interested about this ticket. As of now it appears to be completed - I would appreciate if you take a look and merge it. > migrate core module tests from Junit 3 to 4 > --- > > Key: IGNITE-10175 > URL: https://issues.apache.org/jira/browse/IGNITE-10175 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > If needed, refer parent task for more details. > Migrate using new API introduced at prior step. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10175) migrate core module tests from Junit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713681#comment-16713681
]
Ignite TC Bot commented on IGNITE-10175:
{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=2488187buildTypeId=IgniteTests24Java8_RunAll]
> migrate core module tests from Junit 3 to 4
> ---
>
> Key: IGNITE-10175
> URL: https://issues.apache.org/jira/browse/IGNITE-10175
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> If needed, refer parent task for more details.
> Migrate using new API introduced at prior step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10589) Multiple server node failure after a client node stopping
[
https://issues.apache.org/jira/browse/IGNITE-10589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713658#comment-16713658
]
Ignite TC Bot commented on IGNITE-10589:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Hibernate 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2492264]]
* HibernateL2CacheTransactionalSelfTest.testEntityCacheTransactionFails (last
started)
{color:#d04437}Hibernate 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2492265]]
* HibernateL2CacheTransactionalUseSyncSelfTest.testNaturalIdCache (last started)
{color:#d04437}MVCC Queries{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2492298]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlQueriesTest.testAccountsTxSql_ClientServer_Backups2 -
0,0% fails in last 100 master runs.
{color:#d04437}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2492341]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSplitterSelfTest.testReplicatedTablesUsingPartitionedCacheSegmentedClient
- 0,0% fails in last 100 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2492348buildTypeId=IgniteTests24Java8_RunAll]
> Multiple server node failure after a client node stopping
> -
>
> Key: IGNITE-10589
> URL: https://issues.apache.org/jira/browse/IGNITE-10589
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kosarev
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.8
>
> Attachments: 16_02.tar
>
>
> after stopping a client
> we see topology change and pme finish on the coordinator,
> and at soon on another nodes we still don't see new topology, but have
> Critical error resulting nodes failure
> crd log
> {code}
> 2018-12-06 15:55:23.660 [WARN
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Node FAILED: ZookeeperClusterNode [id=979f03db-f858-44f6-8646-12034dfd5c93,
> addrs=[10.116.206.1], order=129, loc=false, client=true]
> 2018-12-06 15:55:23.660 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Topology snapshot [ver=162, servers=128, clients=0, CPUs=7168,
> offheap=14.0GB, heap=4000.0GB]
> 2018-12-06 15:55:23.660 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- Node [id=44D27930-80E5-4EB7-B377-8B07C02C2033, clusterState=ACTIVE]
> 2018-12-06 15:55:23.660 [INFO
> ][zk-DPL_GRID%DplGridNodeName-EventThread][o.a.i.s.d.z.i.ZookeeperDiscoveryImpl]
> Process alive nodes change [alives=128]
> 2018-12-06 15:55:23.661 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- Baseline [id=0, size=128, online=128, offline=0]
> 2018-12-06 15:55:23.661 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
> Data Regions Configured:
> 2018-12-06 15:55:23.661 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- dpl_mem_plc [initSize=256.0 MiB, maxSize=556.6 GiB,
> persistenceEnabled=true]
> 2018-12-06 15:55:23.661 [INFO
> ][disco-event-worker-#159%DPL_GRID%DplGridNodeName%][o.a.i.i.m.d.GridDiscoveryManager]
>^-- not-persisted [initSize=256.0 MiB, maxSize=556.6 GiB,
> persistenceEnabled=false]
> 2018-12-06 15:55:23.670
> [DEBUG][sys-#564%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.l.ExchangeLatchManager]
> Process node left 979f03db-f858-44f6-8646-12034dfd5c93
> 2018-12-06 15:55:23.670 [INFO
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.exchange.time]
> Started exchange init [topVer=AffinityTopologyVersion [topVer=162,
> minorTopVer=0], crd=true, evt=NODE_FAILED,
> evtNode=979f03db-f858-44f6-8646-12034dfd5c93, customEvt=null, allowMerge=true]
> 2018-12-06 15:55:23.712 [INFO
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.ignite.internal.exchange.time]
> Finished exchange init [topVer=AffinityTopologyVersion [topVer=162,
> minorTopVer=0], crd=true]
> 2018-12-06 15:55:23.699 [INFO
> ][exchange-worker-#160%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture]
> Finish exchange future [startVer=AffinityTopologyVersion [topVer=162,
> minorTopVer=0], resVer=AffinityTopologyVersion [topVer=162, minorTopVer=0],
> err=null]
> {code}
> on a node(1) we have critical error(1)
> {code}
> 2018-12-06 15:55:23.727
> [ERROR][utility-#432%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=1e17c56a-5213-4a1b-b94b-4575a95a2c81,
>
[jira] [Updated] (IGNITE-10177) cleanup Junit 3 from the project
[
https://issues.apache.org/jira/browse/IGNITE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10177:
Description:
If needed, refer parent task for more details.
# remove deprecated API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven
# migrate tests that were missed at prior steps, if there are any
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}} to
add the class via Junit4 adapter
# find and update all Junit3-specific code that {{extends TestCase}}
# untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass which
currently conflict with Junit4 execution because of using constructors and make
them properly use {{@Test}} annotation
# review and if possible upgrade all occurrences of {{import org.junit}} in the
project
# execute junit related inspections of IDE and analyse results
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
was:
If needed, refer parent task for more details.
# remove deprecated API of GridAbstractTest and its subclasses
# remove dependencies from Junit 3 in Maven
# migrate tests that were missed at prior steps, if there are any
# remove redundant references to {{JUnit4.class}} if there are any (like in
{{@RunWith(JUnit4.class)}})
# in tests suite classes, change {{extends TestSuite}} to either
{{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
# check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}} to
add the class via Junit4 adapter
# find and update all Junit3-specific code that {{extends TestCase}}
# untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass which
currently conflict with Junit4 execution because of using constructors and make
them properly use {{@Test}} annotation
# review and if possible upgade all occurrences of {{import org.junit}} in the
project
Side note if for some reason it turns out critically important to keep test
suites names (by default Junit 4 will use suite class names instead), approach
with custom description annotation [described
here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
can be used to address that.
> cleanup Junit 3 from the project
>
>
> Key: IGNITE-10177
> URL: https://issues.apache.org/jira/browse/IGNITE-10177
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Priority: Major
>
> If needed, refer parent task for more details.
> # remove deprecated API of GridAbstractTest and its subclasses
> # remove dependencies from Junit 3 in Maven
> # migrate tests that were missed at prior steps, if there are any
> # remove redundant references to {{JUnit4.class}} if there are any (like in
> {{@RunWith(JUnit4.class)}})
> # in tests suite classes, change {{extends TestSuite}} to either
> {{@RunWith(AllTests.class)}} or {{@Suite.SuiteClasses}}
> # check and adjust if needed methods like {{GridTestUtils.addTestIfNeeded}}
> to add the class via Junit4 adapter
> # find and update all Junit3-specific code that {{extends TestCase}}
> # untangle design of {{IgnitePdsContinuousRestartTest}} and its subclass
> which currently conflict with Junit4 execution because of using constructors
> and make them properly use {{@Test}} annotation
> # review and if possible upgrade all occurrences of {{import org.junit}} in
> the project
> # execute junit related inspections of IDE and analyse results
> Side note if for some reason it turns out critically important to keep test
> suites names (by default Junit 4 will use suite class names instead),
> approach with custom description annotation [described
> here|https://stackoverflow.com/questions/34745080/is-it-possible-to-name-a-test-suite-in-junit-4/34745518]
> can be used to address that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10469) TcpCommunicationSpi does not break tcp connection after IdleConnectionTimeout seconds of inactivity
[
https://issues.apache.org/jira/browse/IGNITE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713611#comment-16713611
]
Stanilovsky Evgeny commented on IGNITE-10469:
-
Igor, i recheck your test under 2.7 ver and looks like it work corrctly, can
you recheck it ?
[^GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java]
> TcpCommunicationSpi does not break tcp connection after IdleConnectionTimeout
> seconds of inactivity
> ---
>
> Key: IGNITE-10469
> URL: https://issues.apache.org/jira/browse/IGNITE-10469
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5, 2.6
>Reporter: Igor Kamyshnikov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Attachments: 2.6.0.txt,
> GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java,
> GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java, ignite_idle_test.zip
>
>
> TcpCommunicationSpi does not close TCP connections after they have been idle
> for more than configured in TcpCommunicationSpi#idleConnTimeout amount of
> time (default is 10 minutes).
> There are environments where idle TCP connections become unusable:
> connections remain ESTABLISHED while actual data to be sent piles up in
> Send-Q (according to netstat). For this reason Ignite stack does not
> recognize a communication problem for a considerable amount of time (~ 10-15
> minutes), and it does not begin its reconnection procedure (hearbeats use
> different tcp connections that are not idle and don't have this issue).
> I've discovered though there is a logic in the Ignite code to detect and
> close idle connections. But due to a problem in the code it does not work
> reliably.
> This is a test that _sometimes_ reproduces the problem.
> [^ignite_idle_test.zip] - full test project
> [^GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java] - just test code
> [^2.6.0.txt] - mvn clean install logs for test with Ignite 2.6.0
> What's the problem in the Ignite code?
> There are two loops in the Ignite code that have a chance to close idle
> connections:
> 1)
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.CommunicationWorker#processIdle
> - this one is executed each *IdleConnectionTimeout* milliseconds. (it can
> close idle connections but it typically turns out that it thinks that
> connection is not idle, thanks to the second loop).
> 2)
> org.apache.ignite.internal.util.nio.GridNioServer.AbstractNioClientWorker#bodyInternal
> ->
> org.apache.ignite.internal.util.nio.GridNioServer.AbstractNioClientWorker#checkIdle
> - this loop executes:
> {noformat}
> filterChain.onSessionIdleTimeout(ses); <-- does not actually close an idle
> connection
> // Update timestamp to avoid multiple notifications within one timeout
> interval.
> ses.resetSendScheduleTime(); <--- resets idle timer
> ses.bytesReceived(0);
> {noformat}
> ---
> To wind up, may be the whole approach should be reviewed:
> - is it ok not to track message delivery time?
> - is it ok not to do heartbeating using the same connections as for
> get/put/... commands?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10469) TcpCommunicationSpi does not break tcp connection after IdleConnectionTimeout seconds of inactivity
[
https://issues.apache.org/jira/browse/IGNITE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-10469:
Attachment: GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java
> TcpCommunicationSpi does not break tcp connection after IdleConnectionTimeout
> seconds of inactivity
> ---
>
> Key: IGNITE-10469
> URL: https://issues.apache.org/jira/browse/IGNITE-10469
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5, 2.6
>Reporter: Igor Kamyshnikov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Attachments: 2.6.0.txt,
> GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java,
> GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java, ignite_idle_test.zip
>
>
> TcpCommunicationSpi does not close TCP connections after they have been idle
> for more than configured in TcpCommunicationSpi#idleConnTimeout amount of
> time (default is 10 minutes).
> There are environments where idle TCP connections become unusable:
> connections remain ESTABLISHED while actual data to be sent piles up in
> Send-Q (according to netstat). For this reason Ignite stack does not
> recognize a communication problem for a considerable amount of time (~ 10-15
> minutes), and it does not begin its reconnection procedure (hearbeats use
> different tcp connections that are not idle and don't have this issue).
> I've discovered though there is a logic in the Ignite code to detect and
> close idle connections. But due to a problem in the code it does not work
> reliably.
> This is a test that _sometimes_ reproduces the problem.
> [^ignite_idle_test.zip] - full test project
> [^GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java] - just test code
> [^2.6.0.txt] - mvn clean install logs for test with Ignite 2.6.0
> What's the problem in the Ignite code?
> There are two loops in the Ignite code that have a chance to close idle
> connections:
> 1)
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.CommunicationWorker#processIdle
> - this one is executed each *IdleConnectionTimeout* milliseconds. (it can
> close idle connections but it typically turns out that it thinks that
> connection is not idle, thanks to the second loop).
> 2)
> org.apache.ignite.internal.util.nio.GridNioServer.AbstractNioClientWorker#bodyInternal
> ->
> org.apache.ignite.internal.util.nio.GridNioServer.AbstractNioClientWorker#checkIdle
> - this loop executes:
> {noformat}
> filterChain.onSessionIdleTimeout(ses); <-- does not actually close an idle
> connection
> // Update timestamp to avoid multiple notifications within one timeout
> interval.
> ses.resetSendScheduleTime(); <--- resets idle timer
> ses.bytesReceived(0);
> {noformat}
> ---
> To wind up, may be the whole approach should be reviewed:
> - is it ok not to track message delivery time?
> - is it ok not to do heartbeating using the same connections as for
> get/put/... commands?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10469) TcpCommunicationSpi does not break tcp connection after IdleConnectionTimeout seconds of inactivity
[
https://issues.apache.org/jira/browse/IGNITE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713611#comment-16713611
]
Stanilovsky Evgeny edited comment on IGNITE-10469 at 12/8/18 9:47 AM:
--
Igor, i recheck your test under 2.7 ver and looks like it work correctly, can
you recheck it ?
[^GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java]
was (Author: zstan):
Igor, i recheck your test under 2.7 ver and looks like it work corrctly, can
you recheck it ?
[^GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java]
> TcpCommunicationSpi does not break tcp connection after IdleConnectionTimeout
> seconds of inactivity
> ---
>
> Key: IGNITE-10469
> URL: https://issues.apache.org/jira/browse/IGNITE-10469
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5, 2.6
>Reporter: Igor Kamyshnikov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Attachments: 2.6.0.txt,
> GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java,
> GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java, ignite_idle_test.zip
>
>
> TcpCommunicationSpi does not close TCP connections after they have been idle
> for more than configured in TcpCommunicationSpi#idleConnTimeout amount of
> time (default is 10 minutes).
> There are environments where idle TCP connections become unusable:
> connections remain ESTABLISHED while actual data to be sent piles up in
> Send-Q (according to netstat). For this reason Ignite stack does not
> recognize a communication problem for a considerable amount of time (~ 10-15
> minutes), and it does not begin its reconnection procedure (hearbeats use
> different tcp connections that are not idle and don't have this issue).
> I've discovered though there is a logic in the Ignite code to detect and
> close idle connections. But due to a problem in the code it does not work
> reliably.
> This is a test that _sometimes_ reproduces the problem.
> [^ignite_idle_test.zip] - full test project
> [^GridTcpCommunicationSpiIdleCommunicationTimeoutTest.java] - just test code
> [^2.6.0.txt] - mvn clean install logs for test with Ignite 2.6.0
> What's the problem in the Ignite code?
> There are two loops in the Ignite code that have a chance to close idle
> connections:
> 1)
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.CommunicationWorker#processIdle
> - this one is executed each *IdleConnectionTimeout* milliseconds. (it can
> close idle connections but it typically turns out that it thinks that
> connection is not idle, thanks to the second loop).
> 2)
> org.apache.ignite.internal.util.nio.GridNioServer.AbstractNioClientWorker#bodyInternal
> ->
> org.apache.ignite.internal.util.nio.GridNioServer.AbstractNioClientWorker#checkIdle
> - this loop executes:
> {noformat}
> filterChain.onSessionIdleTimeout(ses); <-- does not actually close an idle
> connection
> // Update timestamp to avoid multiple notifications within one timeout
> interval.
> ses.resetSendScheduleTime(); <--- resets idle timer
> ses.bytesReceived(0);
> {noformat}
> ---
> To wind up, may be the whole approach should be reviewed:
> - is it ok not to track message delivery time?
> - is it ok not to do heartbeating using the same connections as for
> get/put/... commands?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10607) Add progress-bar component
Alexander Kalinin created IGNITE-10607: -- Summary: Add progress-bar component Key: IGNITE-10607 URL: https://issues.apache.org/jira/browse/IGNITE-10607 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Alexander Kalinin Assignee: Alexander Kalinin Currently we have a progress-line primitive which allows to indicate whether a progress is active or not. But we also need a progress bar with will indicates a percentage of progress using progress line and show percentage. Let's implement one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
