Re: IgniteConfigVariationsAbstractTest subclasses do not run
Hi Ivan F. Thank you for finding it and bringing it here. Please feel free to fix test to run (and fail) if the code it tests is faulty now. If the community knows the moment when tests run will be enabled, it is absolutely not an issue, that TeamCity Bot will complain about new failures. I strongly believe that we should see a true picture of tests output rather than having these tests not running. Sincerely, Dmitriy Pavlov ср, 17 апр. 2019 г. в 22:05, Ivan Rakov : > Hi Ivan, > > I've checked your branch. Seems like these tests fail due to real issue > in functionality. > I'll take a look. > > Best Regards, > Ivan Rakov > > On 17.04.2019 13:54, Ivan Fedotov wrote: > > Hi, Igniters! > > > > During work on iep-30[1] I discovered that > > IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 > tests[2] > > - do not work. > > You can check it just run one of the tests with log output, for example > > ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. > > There is no warning notification in the console. The same situation with > > other IgniteConfigVariationsAbstractTest subclasses - tests run, but they > > simply represent empty code. > > > > So, I created a ticket on such issue [4] and it turned out that the > problem > > is with ruleChain in IgniteConfigVariationsAbstractTest [5]. > > The rule that is responsible for running a test statement does not start > > indeed [6] under ruleChain runRule. I suggested a solution - move > testsCfg > > initialization to > > IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After such > > changes ruleChain becomes not necessary. > > > > But I faced another problem - multiple failures on TeamCity [7]. From > logs, > > it seems that failures are related to what tests check, but not JUnit > error. > > I can not track TeamCity history on that fact were tests failed or not on > > the previous JUnit version - the oldest log is dated the start of the > March > > when JUnit4 > > already was implemented (for example, this [8] test). > > Moreover, there are not so much failed tests, but because of running with > > multiple configurations > (InterceptorCacheConfigVariationsFullApiTestSuite_0 > > ..._95) it turns out about 400 failed tests. TeamCity results also > confirm > > that tests do not work in the master branch - duration time is less than > > 1ms. Now all tests are green and that is not surprising - under @Test > > annotation, nothing happens. > > > > Could some of us confirm or disprove my guess that tests are red because > of > > its functionality, but not JUnit implementation? > > And if it is true, how should I take such fact into account in this > ticket? > > > > [1] > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > > [2] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java > > [3] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 > > [4] https://issues.apache.org/jira/browse/IGNITE-11708 > > [5] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 > > [6] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 > > [7] > > > https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest > > [8] > > > https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8 > > >
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Hi Ivan, I've checked your branch. Seems like these tests fail due to real issue in functionality. I'll take a look. Best Regards, Ivan Rakov On 17.04.2019 13:54, Ivan Fedotov wrote: Hi, Igniters! During work on iep-30[1] I discovered that IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 tests[2] - do not work. You can check it just run one of the tests with log output, for example ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. There is no warning notification in the console. The same situation with other IgniteConfigVariationsAbstractTest subclasses - tests run, but they simply represent empty code. So, I created a ticket on such issue [4] and it turned out that the problem is with ruleChain in IgniteConfigVariationsAbstractTest [5]. The rule that is responsible for running a test statement does not start indeed [6] under ruleChain runRule. I suggested a solution - move testsCfg initialization to IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After such changes ruleChain becomes not necessary. But I faced another problem - multiple failures on TeamCity [7]. From logs, it seems that failures are related to what tests check, but not JUnit error. I can not track TeamCity history on that fact were tests failed or not on the previous JUnit version - the oldest log is dated the start of the March when JUnit4 already was implemented (for example, this [8] test). Moreover, there are not so much failed tests, but because of running with multiple configurations (InterceptorCacheConfigVariationsFullApiTestSuite_0 ..._95) it turns out about 400 failed tests. TeamCity results also confirm that tests do not work in the master branch - duration time is less than 1ms. Now all tests are green and that is not surprising - under @Test annotation, nothing happens. Could some of us confirm or disprove my guess that tests are red because of its functionality, but not JUnit implementation? And if it is true, how should I take such fact into account in this ticket? [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 [2] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java [3] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 [4] https://issues.apache.org/jira/browse/IGNITE-11708 [5] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 [6] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 [7] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest [8] https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8
Re: Code inspection
Maxim, I looked through the PR and it looks good to me in general. The only question how it's planned to maintain check styles in 2 different configurations, for IDEA and check style plugin? On Mon, Mar 25, 2019 at 12:30 PM Maxim Muzafarov wrote: > > Igniters, > > The issue [1] with enabled maven-checkstyle-plugin is ready for the review. > All changes are prepared according to e-mail [2] the second option > point (include the plugin in the maven build procedure by default). > > JIRA: IGNITE-11277 [1] > PR: [3] > Upsource: [4] > > How can take a look? > > [1] https://issues.apache.org/jira/browse/IGNITE-11277 > [2] > http://apache-ignite-developers.2346864.n4.nabble.com/Code-inspection-tp27709p41297.html > [3] https://github.com/apache/ignite/pull/6119 > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1018 > > On Fri, 15 Mar 2019 at 19:19, Dmitriy Pavlov wrote: > > > > Hi Igniters, > > > > I see that a new TeamCity is released: Version: 2018.2.3. > > > > Probably it could solve recently introduced problem related to: > > Unexpected error during build messages processing in TeamCity; > > > > Peter I., could you please check? > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван : > > > > > I agree to gather some votes according to Maxim's proposal. > > > > > > Personally, I will not put my vote here. Both options will work for me > > > today. > > > > > > But I would like to say a bit about agility. As I said both options > > > sounds fine for me today. And I believe that we can switch from one to > > > another easily in future. Let's do our best to be flexible. > > > > > > пт, 15 мар. 2019 г. в 12:04, Павлухин Иван : > > > > > > > > Maxim, > > > > > > > > > As far as I understand your case, you want to fix all code styles > > > > issues right before getting the final TC results. Right? ... > > > > > > > > Actually, I mostly worry about accidental failures. For simple tasks > > > > my workflow looks like: > > > > 1. Create a branch. > > > > 2. Write some code lines and tests. > > > > 3. Run the most closely related tests from IDEA. > > > > 4. Push changes to the branch. > > > > 5. Launch TC. > > > > 6. Take a cup of coffee ;-) > > > > 7. Check TC results after a couple of hours. > > > > > > > > And in such workflow I can accidentally leave styling error (IDEA does > > > > not fail compilation). And I will receive not very valuable report > > > > from TC. And will have to wait for another couple of hours. > > > > > > > > Yes, usually I do not execute "mvn clean install" locally before > > > > triggering TC. And I think that generally we should not do it because > > > > TC does it. > > > > > > > > If not everybody uses a bot visas it sounds bad for me. For patches > > > > touching the code it should be mandatory. Also, as you might know > > > > there are different kind of visas and for some trivial patches we can > > > > request Checkstyle visa. Committers should check formalities. > > > > > > > > пт, 15 мар. 2019 г. в 10:29, Nikolay Izhikov : > > > > > > > > > > +1 to enable code style checks in compile time. > > > > > > > > > > We can add option to disable maven codestyle profile with some > > > environment variable. > > > > > > > > > > Anyone who want violate common project rules in their local branch can > > > set this variable and write some nasty code before push :) > > > > > > > > > > пт, 15 марта 2019 г., 9:40 Maxim Muzafarov : > > > > >> > > > > >> Ivan, > > > > >> > > > > >> > 1. I can write code and execute tests successfully even if there > > > > >> > are > > > > >> some style problems. I can imagine that a style error can arise > > > > >> occasionally. And instead of getting test results after several hours > > > > >> I will get a build failure without any tests run. I will simply lose > > > > >> my time. But if the tests are allowed to proceed I will get a red > > > > >> flag > > > > >> from code style check, fix those issues and rerun style check. > > > > >> > > > > >> As far as I understand your case, you want to fix all code styles > > > > >> issues right before getting the final TC results. Right? It's doable > > > > >> you can disable checkstyle in your local branch and revet it back > > > > >> when > > > > >> you've done with all your changes to get the final visa. But the > > > > >> common case here is building the project locally and checking all > > > > >> requirements for PR right before pushing it to the GitHub repo. I > > > > >> always do so. The "Checklist before push" [1] have such > > > > >> recommendations. Build the project before push will eliminate your > > > > >> use > > > > >> case. > > > > >> > > > > >> --- > > > > >> > > > > >> Igniters, > > > > >> > > > > >> To summarize the options we have with code checking behaviour: > > > > >> > > > > >> 1) (code style will be broken more often) Run checkstyle in the > > > > >> separate TC suite and include it to the Bot visa. > > > > >> - not all of us run TC for their
[jira] [Created] (IGNITE-11769) Investigate JVM crash in PDS Direct IO TeamCity suites
Ivan Rakov created IGNITE-11769:
---
Summary: Investigate JVM crash in PDS Direct IO TeamCity suites
Key: IGNITE-11769
URL: https://issues.apache.org/jira/browse/IGNITE-11769
Project: Ignite
Issue Type: Bug
Reporter: Ivan Rakov
Fix For: 2.8
Both PDS Direct IO suites periodically fail with JVM crash.
The issue can be reproduced on Linux machine by running
IgnitePdsWithTtlTest#testTtlIsAppliedAfterRestart using ignite-direct-io
classpath.
The investigation is complicated because JVM crash report* is not generated*
during this crash. After some point, JVM stays dormant for 2 minutes and then
process gets killed by OS signal
{code:java}
Process finished with exit code 134 (interrupted by signal 6: SIGABRT
{code}
and the following error messages can be dumped to stderr before process death
{code:java}
`corrupted double-linked list`
`free(): corrupted unsorted chunks`
{code}
which appear to be libc error messages. Seems like Ignite corrupts virtual
memory in sophisticated way which prevents normal JVM Crash flow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: newbie + kubernetes IpFinder
Hello Balazs, Thanks for reaching the community out. Certainly, we'll appreciate if you contribute your changes back. Could you please create a ticket in JIRA and open the pull-request? Someone from the community will review and accept your improvements. Just in case, you can find more on contribution here: https://ignite.apache.org/community/contribute.html#contribute - Denis On Wed, Apr 17, 2019 at 8:03 AM Péterfi, Balázs wrote: > Hi All, > > First of all I wanted to say hi as I've just joined to the list! > > Secondly, I'm moving one of my apps to Kubernetes and found > the ignite-kubernetes lib for finding the pods for the cluster. After > playing with it a bit I found out that it won't work for me, because it > only collects the IPs for the pods that are in a ready state. My problem > with that is when my app is starting it warms up the cache which takes some > time and only when this is done will it have a ready state in k8s. But at > that point all my pods have started a single node cluster and they end up > in a split-brain scenario (not to mention that they all did the cache > warm-up which is a waste). In Hazelcast they have a flag to include > non-ready pods as well which solves the issue. I have an implementation for > that and would be happy to add it in the original IpFinder with some > configuration to control that behavior, unless someone here tells me > otherwise. > > There is another change I did on the original version which is to prevent > two ReplicaSets of the same app joining to each-other's cluster. This is a > must have for me when deploying a new version while leaving the old one > running until the warm-up finishes. I couldn't find any configuration that > prevents this happening so I changed the IpFinder to only look for pods > from the same ReplicaSet. I wonder if there is any other solution for this > issue? > > Best regards, > Balazs >
[jira] [Created] (IGNITE-11768) CPP documentation:mention default BinaryType methods implementation
Igor Sapego created IGNITE-11768: Summary: CPP documentation:mention default BinaryType methods implementation Key: IGNITE-11768 URL: https://issues.apache.org/jira/browse/IGNITE-11768 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.7 Reporter: Igor Sapego Fix For: 2.8 Mention BinaryTypeDefaultHashing, BinaryTypeNonNullableType and BinaryTypeDefaultAll classes introduced in IGNITE-11703 in documentation. Also, use them where it is possible and appropriate in code snippets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11767) GridDhtPartitionsFullMessage retains huge maps on heap ion exchange history
Ilya Kasnacheev created IGNITE-11767: Summary: GridDhtPartitionsFullMessage retains huge maps on heap ion exchange history Key: IGNITE-11767 URL: https://issues.apache.org/jira/browse/IGNITE-11767 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.7 Reporter: Ilya Kasnacheev ExchangeHistory keeps a FinishState for every topology version. FinishState contains msg, which contains at least two huge maps: partCntrs2 and partsSizesBytes. We should probably strip msg, removing those two data structures before putting msg in exchFuts linked list to be stowed away. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
newbie + kubernetes IpFinder
Hi All, First of all I wanted to say hi as I've just joined to the list! Secondly, I'm moving one of my apps to Kubernetes and found the ignite-kubernetes lib for finding the pods for the cluster. After playing with it a bit I found out that it won't work for me, because it only collects the IPs for the pods that are in a ready state. My problem with that is when my app is starting it warms up the cache which takes some time and only when this is done will it have a ready state in k8s. But at that point all my pods have started a single node cluster and they end up in a split-brain scenario (not to mention that they all did the cache warm-up which is a waste). In Hazelcast they have a flag to include non-ready pods as well which solves the issue. I have an implementation for that and would be happy to add it in the original IpFinder with some configuration to control that behavior, unless someone here tells me otherwise. There is another change I did on the original version which is to prevent two ReplicaSets of the same app joining to each-other's cluster. This is a must have for me when deploying a new version while leaving the old one running until the warm-up finishes. I couldn't find any configuration that prevents this happening so I changed the IpFinder to only look for pods from the same ReplicaSet. I wonder if there is any other solution for this issue? Best regards, Balazs
IgniteConfigVariationsAbstractTest subclasses do not run
Hi, Igniters! During work on iep-30[1] I discovered that IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 tests[2] - do not work. You can check it just run one of the tests with log output, for example ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. There is no warning notification in the console. The same situation with other IgniteConfigVariationsAbstractTest subclasses - tests run, but they simply represent empty code. So, I created a ticket on such issue [4] and it turned out that the problem is with ruleChain in IgniteConfigVariationsAbstractTest [5]. The rule that is responsible for running a test statement does not start indeed [6] under ruleChain runRule. I suggested a solution - move testsCfg initialization to IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After such changes ruleChain becomes not necessary. But I faced another problem - multiple failures on TeamCity [7]. From logs, it seems that failures are related to what tests check, but not JUnit error. I can not track TeamCity history on that fact were tests failed or not on the previous JUnit version - the oldest log is dated the start of the March when JUnit4 already was implemented (for example, this [8] test). Moreover, there are not so much failed tests, but because of running with multiple configurations (InterceptorCacheConfigVariationsFullApiTestSuite_0 ..._95) it turns out about 400 failed tests. TeamCity results also confirm that tests do not work in the master branch - duration time is less than 1ms. Now all tests are green and that is not surprising - under @Test annotation, nothing happens. Could some of us confirm or disprove my guess that tests are red because of its functionality, but not JUnit implementation? And if it is true, how should I take such fact into account in this ticket? [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 [2] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java [3] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 [4] https://issues.apache.org/jira/browse/IGNITE-11708 [5] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 [6] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 [7] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest [8] https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8 -- Ivan Fedotov. ivanan...@gmail.com
[jira] [Created] (IGNITE-11766) cpp: JVM library not found for openjdk 11 on windows
Stepan Pilschikov created IGNITE-11766:
--
Summary: cpp: JVM library not found for openjdk 11 on windows
Key: IGNITE-11766
URL: https://issues.apache.org/jira/browse/IGNITE-11766
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Stepan Pilschikov
Trying to run compiled ignite.exe from platforms/cpp on windows
{code}
An error occurred: JVM library is not found (did you set JAVA_HOME environment
variable?)
{code}
Think problem that platforms\cpp\jni\os\win\src\utils -> JAVA_DDL =
"\\jre\\bin\\server\\jvm.dll"
searching for jre in jdk dir ectory
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11765) Vulnerable library H2 Database Engine1.4.197 used
VIJAY BHATT created IGNITE-11765: Summary: Vulnerable library H2 Database Engine1.4.197 used Key: IGNITE-11765 URL: https://issues.apache.org/jira/browse/IGNITE-11765 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: VIJAY BHATT We use blackduck for scanning our project. It has identified Ignite 2.7.0 using H2 Database Engine version 1.4.197 as a vulnerable library having the following 2 vulnerabilities: BDSA-2018-1048 (CVE-2018-10054) BDSA-2018-2507 (CVE-2018-14335) Suggested fix by blackduck is to use version 1.4.198 We tried using 1.4.198 using jar override but it has some breaking changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[DISCUSSION] Simplification of Ignite options and cache configuration
Dear Ignite developers, I have some ideas about Ignite 3.0 release and simplifications that might be included in the future release: 1. Remove *_ENABLED/*_DISABLED from Ignite system properties. I see only one advantage in this case - some information about default value: e.g. _ENABLED property is disabled by default. On the other hand, you need to know is this property ends with _ENABLED to _DISABLED. Removing these additions makes property names more clear and they will be easy to remember and use (default values could be found in search engine as before) (https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html) 2. Group similar properties into sub-objects in CacheConfiguration. For example, all SQL properties may be in some SQLCacheConfiguration object, writeThrough/readThrough may be in some sub-object as well. This change makes CacheConfiguration class more clear and XML cache configuration itself much easier to configure - the user has information about all properties in context and which of them are mandatory. Best regards, Dmitriy Sherstobitov
[jira] [Created] (IGNITE-11764) SQL: Do not use two step query in the case of single node cluster
Roman Kondakov created IGNITE-11764: --- Summary: SQL: Do not use two step query in the case of single node cluster Key: IGNITE-11764 URL: https://issues.apache.org/jira/browse/IGNITE-11764 Project: Ignite Issue Type: Improvement Components: sql Reporter: Roman Kondakov We can avoid using two step query in the case of the single-node cluster. The decision about the local execution should be made on the reducer step as well as partition pruning optimization does. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11763) GridP2PComputeWithNestedEntryProcessorTest failed on TC
Vladislav Pyatkov created IGNITE-11763:
--
Summary: GridP2PComputeWithNestedEntryProcessorTest failed on TC
Key: IGNITE-11763
URL: https://issues.apache.org/jira/browse/IGNITE-11763
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
Test failed with exception:
{noformat}
[2019-04-16 19:50:21,725][ERROR][main][root] Test failed.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to execute query on node [query=GridCacheQueryBean
[qry=GridCacheQueryAdapter [type=SCAN, clsName=null, clause=null,
filter=org.apache.ignite.tests.p2p.pedicates.CompositePredicate@2b939b78,
transform=null, part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter
[minTime=9223372036854775807, maxTime=0, sumTime=0, avgTime=0.0, execs=0,
completed=0, fails=0], pageSize=1024, timeout=0, incBackups=false,
forceLocal=false, dedup=false, prj=null, keepBinary=true,
subjId=008694d2-98a2-4add-9ccc-b7674e6d717f, taskHash=0, mvccSnapshot=null,
dataPageScanEnabled=null], rdc=null, trans=null],
nodeId=8575809f-3373-4c47-8684-a318c221]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1318)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:168)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$5.onHasNext(GridCacheDistributedQueryManager.java:643)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:123)
at
org.apache.ignite.p2p.GridP2PComputeWithNestedEntryProcessorTest.scanByCopositeFirstPredicate(GridP2PComputeWithNestedEntryProcessorTest.java:205)
at
org.apache.ignite.p2p.GridP2PComputeWithNestedEntryProcessorTest.scnaCacheData(GridP2PComputeWithNestedEntryProcessorTest.java:188)
at
org.apache.ignite.p2p.GridP2PComputeWithNestedEntryProcessorTest.processTest(GridP2PComputeWithNestedEntryProcessorTest.java:140)
at
org.apache.ignite.p2p.GridP2PComputeWithNestedEntryProcessorTest.testContinuousMode(GridP2PComputeWithNestedEntryProcessorTest.java:105)
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
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
clsName=null, clause=null,
filter=org.apache.ignite.tests.p2p.pedicates.CompositePredicate@2b939b78,
transform=null, part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter
[minTime=9223372036854775807, maxTime=0, sumTime=0, avgTime=0.0, execs=0,
completed=0, fails=0], pageSize=1024, timeout=0, incBackups=false,
forceLocal=false, dedup=false, prj=null, keepBinary=true,
subjId=008694d2-98a2-4add-9ccc-b7674e6d717f, taskHash=0, mvccSnapshot=null,
dataPageScanEnabled=null], rdc=null, trans=null],
nodeId=8575809f-3373-4c47-8684-a318c221]
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:384)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryResponse(GridCacheDistributedQueryManager.java:402)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.access$000(GridCacheDistributedQueryManager.java:64)
at
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:94)
at
