[jira] [Commented] (IGNITE-12002) [TTL] Some expired data remains in memory even with eager TTL enabled
[ https://issues.apache.org/jira/browse/IGNITE-12002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891619#comment-16891619 ] Ivan Pavlukhin commented on IGNITE-12002: - [~panes], kind of discussion was held in http://apache-ignite-developers.2346864.n4.nabble.com/apache-Ignite-2-8-release-date-td42748.html I suppose it means at least that it will be no earlier than October. > [TTL] Some expired data remains in memory even with eager TTL enabled > - > > Key: IGNITE-12002 > URL: https://issues.apache.org/jira/browse/IGNITE-12002 > Project: Ignite > Issue Type: Bug > Components: cache, general >Affects Versions: 2.7 > Environment: Running on MacOS 10.12.6 > OpenJDK 11 > Ignite v2.7.0 > >Reporter: Philippe Anes >Priority: Major > > Create an ignite client (in client mode false) and put some data (10k > entries/values) to it with very small expiration time (~20s) and TTL enabled. > Each time the thread is running it'll remove all the entries that expired, > but after few attempts this thread is not removing all the expired entries, > some of them are staying in memory and are not removed by this thread > execution. > That means we got some expired data in memory, and it's something we want to > avoid. > Please can you confirm that is a real issue or just misuse/configuration of > my test? > Thanks for your feedback. > > To reproduce: > Git repo: [https://github.com/panes/ignite-sample] > Run MyIgniteLoadRunnerTest.run() to reproduce the issue described on top. > (Global setup: Writing 10k entries of 64octets each with TTL 10s) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12005) AssertionError when put/get byte arrays in cache
[
https://issues.apache.org/jira/browse/IGNITE-12005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891336#comment-16891336
]
Semen Boikov commented on IGNITE-12005:
---
[~Vladimir Pligin], looks like some other issue, IGNITE-11953 is already fixed,
but this error reproduces on latest master.
> AssertionError when put/get byte arrays in cache
>
>
> Key: IGNITE-12005
> URL: https://issues.apache.org/jira/browse/IGNITE-12005
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Semen Boikov
>Priority: Critical
> Attachments: CachePutGetByteArrays.java
>
>
> In attachment test executes puts in cache byte arrays with various sizes
> (among them arrays with size > page size). After this assert fails on
> cache.get:
> {noformat}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1544803905,
> val2=844420635164743]], msg=Runtime failure on lookup row: SearchRow
> [key=org.apache.ignite.internal.processors.cache.distributed.CachePutGetByteArrays$TestKey
> [idHash=209014132, hash=-1084267651, id=9091, dummyData=[0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
[jira] [Updated] (IGNITE-12008) thick client has all system threads busy indefinitely
[ https://issues.apache.org/jira/browse/IGNITE-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahesh Renduchintala updated IGNITE-12008: -- Attachment: poolthreadstarvation.log > thick client has all system threads busy indefinitely > - > > Key: IGNITE-12008 > URL: https://issues.apache.org/jira/browse/IGNITE-12008 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.7 >Reporter: Mahesh Renduchintala >Priority: Critical > Attachments: config.zip, poolthreadstarvation.log > > > Please refer to this thread. All logs are attached on this thread. > [http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-7-0-thick-client-has-all-system-threads-busy-indefinitely-td28880.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12008) thick client has all system threads busy indefinitely
[ https://issues.apache.org/jira/browse/IGNITE-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahesh Renduchintala updated IGNITE-12008: -- Attachment: config.zip > thick client has all system threads busy indefinitely > - > > Key: IGNITE-12008 > URL: https://issues.apache.org/jira/browse/IGNITE-12008 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.7 >Reporter: Mahesh Renduchintala >Priority: Critical > Attachments: config.zip > > > Please refer to this thread. All logs are attached on this thread. > [http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-7-0-thick-client-has-all-system-threads-busy-indefinitely-td28880.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12008) thick client has all system threads busy indefinitely
Mahesh Renduchintala created IGNITE-12008: - Summary: thick client has all system threads busy indefinitely Key: IGNITE-12008 URL: https://issues.apache.org/jira/browse/IGNITE-12008 Project: Ignite Issue Type: Bug Components: clients Affects Versions: 2.7 Reporter: Mahesh Renduchintala Attachments: config.zip Please refer to this thread. All logs are attached on this thread. [http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-7-0-thick-client-has-all-system-threads-busy-indefinitely-td28880.html] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-10761) GridCacheProcessor should add info about cache in excecption message, if applicable.
[ https://issues.apache.org/jira/browse/IGNITE-10761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891297#comment-16891297 ] Ivan Rakov commented on IGNITE-10761: - [~ktkale...@gridgain.com], thanks, merged to master. > GridCacheProcessor should add info about cache in excecption message, if > applicable. > - > > Key: IGNITE-10761 > URL: https://issues.apache.org/jira/browse/IGNITE-10761 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > > We should add info about problem cache in exception message. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891243#comment-16891243 ] Ivan Fedotov edited comment on IGNITE-10973 at 7/23/19 5:54 PM: [~Pavlukhin] , According to Parametrized test - I added a new dependency in the last commit. We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is simplier than in the fourth version. Rule and ClassRule annotations can be replaced by Extension and ExtendWith respectively. According to .net tests: the reason for failures is the only one: "The filename or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath because other args are hardcoded. I compared the log files from my branch [2] and master [3]. For some reason, jvmClasspath contains all maven dependencies. Because of addition more dependencies to pom file, this string becomes too long for system .net function. I guess that it is not correct behavior of Classpath.cs#CreateClasspath function, because if we need to add some more dependencies to pom file, we faced this problem. Moreover, it is not jvmClasspath, it's the enumeration of all jat files. [1] [https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148] [2] [https://ci.ignite.apache.org/viewLog.html?buildId=4318302&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning] [3] [https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=4381131&_focus=53179] was (Author: ivanan.fed): [~Pavlukhin] , According to Parametrized test - I added a new dependency in the last commit. We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is simplier than in the fourth version. Rule and ClassRule annotations can be replaced by Extension and ExtendWith respectively. According to .net tests: the reason for failures is the only one: "The filename or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath because other args are hardcoded. I compared the log files from my branch[2] and master[3]. For some reason, jvmClasspath contains all maven dependencies. Because of addition more dependencies to pom file, this string becomes too long for system .net function. I guess that it is not correct behavior of Classpath.cs#CreateClasspath function, because if we need to add some more dependencies to pom file, we faced this problem. Moreover, it is not jvmClasspath, it's the enumeration of all jat files. [1] [https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148] [2] [https://ci.ignite.apache.org/viewLog.html?buildId=4318302&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning] [3] [https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=4381131&_focus=53179] > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken
[
https://issues.apache.org/jira/browse/IGNITE-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891245#comment-16891245
]
Dmitriy Pavlov edited comment on IGNITE-12007 at 7/23/19 5:45 PM:
--
Web console image is not shipped during Ignite release anymore.
Latest 2.7.5 version was not deployed and there are no plans to restore it,
until someone volunteers to do it
was (Author: dpavlov):
Web console image is not shipped during Ignite release. Latest 2.7.5 version
was not deployed and there are no plans to restore it
> Latest "apacheignite/web-console-backend" docker image is broken
>
>
> Key: IGNITE-12007
> URL: https://issues.apache.org/jira/browse/IGNITE-12007
> Project: Ignite
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.7
>Reporter: Igor Belyakov
>Priority: Critical
>
> It's not possible to run docker container by using the latest version of
> "apacheignite/web-console-backend" image.
> Next error happens on the start:
> {code:java}
> npm ERR! A complete log of this run can be found in:
> npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
> npm ERR! path /opt/web-console/package.json
> npm ERR! code ENOENT
> npm ERR! errno -2
> npm ERR! syscall open
> npm ERR! enoent ENOENT: no such file or directory, open
> '/opt/web-console/package.json'
> npm ERR! enoent This is related to npm not being able to find a file.
> npm ERR! enoent{code}
> How to reproduce:
> Run container by using docker-compose as described here:
> [https://hub.docker.com/r/apacheignite/web-console-backend]
>
> Seems like it was broken by the next commit:
> [https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891243#comment-16891243 ] Ivan Fedotov edited comment on IGNITE-10973 at 7/23/19 5:44 PM: [~Pavlukhin] , According to Parametrized test - I added a new dependency in the last commit. We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is simplier than in the fourth version. Rule and ClassRule annotations can be replaced by Extension and ExtendWith respectively. According to .net tests: the reason for failures is the only one: "The filename or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath because other args are hardcoded. I compared the log files from my branch[2] and master[3]. For some reason, jvmClasspath contains all maven dependencies. Because of addition more dependencies to pom file, this string becomes too long for system .net function. I guess that it is not correct behavior of Classpath.cs#CreateClasspath function, because if we need to add some more dependencies to pom file, we faced this problem. Moreover, it is not jvmClasspath, it's the enumeration of all jat files. [1] [https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148] [2] [https://ci.ignite.apache.org/viewLog.html?buildId=4318302&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning] [3] [https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=4381131&_focus=53179] was (Author: ivanan.fed): [~Pavlukhin] , According to Parametrized test - I added a new dependency in the last commit. We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is simplier than in the fourth version. Rule and ClassRule annotations can be replaced by Extension and ExtendWith respectively. According to .net tests: the reason for failures is the only one: "The filename or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath because other args are hardcoded. I compared the log files from my branch[2] and master[3]. For some reason, jvmClasspath contains all maven dependencies. Because of addition more dependencies to pom file, this string becomes too long for system .net function. I guess that it is not correct behavior of Classpath.cs#CreateClasspath function, because if we need to add some more dependencies to pom file, we faced this problem. Moreover, it is not jvmClasspath, it's the enumeration of all jat files. [1] https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148 [2] https://ci.ignite.apache.org/viewLog.html?buildId=4318302&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning [3] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=4381131&_focus=53179 > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken
[
https://issues.apache.org/jira/browse/IGNITE-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov resolved IGNITE-12007.
-
Resolution: Won't Fix
Web console image is not shipped during Ignite release. Latest 2.7.5 version
was not deployed and there are no plans to restore it
> Latest "apacheignite/web-console-backend" docker image is broken
>
>
> Key: IGNITE-12007
> URL: https://issues.apache.org/jira/browse/IGNITE-12007
> Project: Ignite
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.7
>Reporter: Igor Belyakov
>Priority: Critical
>
> It's not possible to run docker container by using the latest version of
> "apacheignite/web-console-backend" image.
> Next error happens on the start:
> {code:java}
> npm ERR! A complete log of this run can be found in:
> npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
> npm ERR! path /opt/web-console/package.json
> npm ERR! code ENOENT
> npm ERR! errno -2
> npm ERR! syscall open
> npm ERR! enoent ENOENT: no such file or directory, open
> '/opt/web-console/package.json'
> npm ERR! enoent This is related to npm not being able to find a file.
> npm ERR! enoent{code}
> How to reproduce:
> Run container by using docker-compose as described here:
> [https://hub.docker.com/r/apacheignite/web-console-backend]
>
> Seems like it was broken by the next commit:
> [https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891243#comment-16891243 ] Ivan Fedotov commented on IGNITE-10973: --- [~Pavlukhin] , According to Parametrized test - I added a new dependency in the last commit. We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is simplier than in the fourth version. Rule and ClassRule annotations can be replaced by Extension and ExtendWith respectively. According to .net tests: the reason for failures is the only one: "The filename or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath because other args are hardcoded. I compared the log files from my branch[2] and master[3]. For some reason, jvmClasspath contains all maven dependencies. Because of addition more dependencies to pom file, this string becomes too long for system .net function. I guess that it is not correct behavior of Classpath.cs#CreateClasspath function, because if we need to add some more dependencies to pom file, we faced this problem. Moreover, it is not jvmClasspath, it's the enumeration of all jat files. [1] https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148 [2] https://ci.ignite.apache.org/viewLog.html?buildId=4318302&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning [3] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=4381131&_focus=53179 > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken
Igor Belyakov created IGNITE-12007:
--
Summary: Latest "apacheignite/web-console-backend" docker image is
broken
Key: IGNITE-12007
URL: https://issues.apache.org/jira/browse/IGNITE-12007
Project: Ignite
Issue Type: Bug
Components: UI
Affects Versions: 2.7
Reporter: Igor Belyakov
It's not possible to run docker container by using the latest version of
"apacheignite/web-console-backend" image.
Next error happens on the start:
{code:java}
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
npm ERR! path /opt/web-console/package.json
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open
'/opt/web-console/package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent{code}
How to reproduce:
Run container by using docker-compose as described here:
[https://hub.docker.com/r/apacheignite/web-console-backend]
Seems like it was broken by the next commit:
[https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12002) [TTL] Some expired data remains in memory even with eager TTL enabled
[ https://issues.apache.org/jira/browse/IGNITE-12002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891122#comment-16891122 ] Philippe Anes commented on IGNITE-12002: Thanks [~Pavlukhin], I pushed to my sample repository the use of ignite version 2.8.0.20190723 and I confirm that I cannot reproduce the issue anymore. Do you know if we could expect this fix to be merged as a patch to ignite 2.7.6? Or should we wait to ignite 2.8.0? If yes do we have any ETA on its availability? > [TTL] Some expired data remains in memory even with eager TTL enabled > - > > Key: IGNITE-12002 > URL: https://issues.apache.org/jira/browse/IGNITE-12002 > Project: Ignite > Issue Type: Bug > Components: cache, general >Affects Versions: 2.7 > Environment: Running on MacOS 10.12.6 > OpenJDK 11 > Ignite v2.7.0 > >Reporter: Philippe Anes >Priority: Major > > Create an ignite client (in client mode false) and put some data (10k > entries/values) to it with very small expiration time (~20s) and TTL enabled. > Each time the thread is running it'll remove all the entries that expired, > but after few attempts this thread is not removing all the expired entries, > some of them are staying in memory and are not removed by this thread > execution. > That means we got some expired data in memory, and it's something we want to > avoid. > Please can you confirm that is a real issue or just misuse/configuration of > my test? > Thanks for your feedback. > > To reproduce: > Git repo: [https://github.com/panes/ignite-sample] > Run MyIgniteLoadRunnerTest.run() to reproduce the issue described on top. > (Global setup: Writing 10k entries of 64octets each with TTL 10s) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IGNITE-9634) [ML] Trainers as pipeline parameters that can be varied
[ https://issues.apache.org/jira/browse/IGNITE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-9634. -- Resolution: Won't Fix > [ML] Trainers as pipeline parameters that can be varied > --- > > Key: IGNITE-9634 > URL: https://issues.apache.org/jira/browse/IGNITE-9634 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.8 > > > Based > http://apache-ignite-developers.2346864.n4.nabble.com/ML-New-Feature-Trainers-as-pipeline-parameters-that-can-be-varied-td35132.html -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-9633) [ML] Hyper-parameter tuning via Genetic Algorithm
[ https://issues.apache.org/jira/browse/IGNITE-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-9633: - Summary: [ML] Hyper-parameter tuning via Genetic Algorithm (was: [ML] Hyperparameter tuning improvements umbrella ticket) > [ML] Hyper-parameter tuning via Genetic Algorithm > - > > Key: IGNITE-9633 > URL: https://issues.apache.org/jira/browse/IGNITE-9633 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Minor > Fix For: 2.8 > > > Umbrella ticket for all hyperparameter tuning improvements -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-11410) Providing a restricted environment in which to run user-defined code securely
[ https://issues.apache.org/jira/browse/IGNITE-11410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-11410: - Summary: Providing a restricted environment in which to run user-defined code securely (was: Security Engine fixes and test coverage. Phase #2.) > Providing a restricted environment in which to run user-defined code securely > - > > Key: IGNITE-11410 > URL: https://issues.apache.org/jira/browse/IGNITE-11410 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Denis Garus >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > We should provide a restricted environment in which to run user-defined code > securely. To get it done, we would use the java sandbox model. > The java sandbox model allows restricting access from user-defined code to > the system resources or security-sensitive feature of java, for example, > reflection. > The user-defined code contains: > - StreamReceiver for DataStreamer: > - EntryProcessor; > - ComputeJob; > - filter and transformer for ScanQuery. > The user-defined code will get permissions from GridSecuerityProcessor > (security plugin). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-11993) Print warning if awaiting next wal segment it too long
[ https://issues.apache.org/jira/browse/IGNITE-11993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890867#comment-16890867 ] Sergey Chugunov commented on IGNITE-11993: -- [~ktkale...@gridgain.com], patch looks good to me as well. Lets merge it to master branch. Thank you for contribution! > Print warning if awaiting next wal segment it too long > -- > > Key: IGNITE-11993 > URL: https://issues.apache.org/jira/browse/IGNITE-11993 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We must print warn to log, if awaiting next WAL segment more then defined > threshold. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12006) Threads may be parked for indefinite time during throttling after spurious wakeups
Sergey Antonov created IGNITE-12006:
---
Summary: Threads may be parked for indefinite time during
throttling after spurious wakeups
Key: IGNITE-12006
URL: https://issues.apache.org/jira/browse/IGNITE-12006
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Assignee: Sergey Antonov
In the log we see the following behavior:
{noformat}
2019-07-04 06:29:03.649[WARN
][sys-#328%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#328%NODE%xyzGridNodeName% for timeout(ms)=16335
2019-07-04 06:29:03.649[WARN
][sys-#326%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#326%NODE%xyzGridNodeName% for timeout(ms)=13438
2019-07-04 06:29:03.649[WARN
][sys-#277%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#277%NODE%xyzGridNodeName% for timeout(ms)=11609
2019-07-04 06:29:03.649[WARN
][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=18009
2019-07-04 06:29:03.649[WARN
][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=15557
2019-07-04 06:29:03.650[WARN
][sys-#307%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#307%NODE%xyzGridNodeName% for timeout(ms)=27938
2019-07-04 06:29:03.649[WARN
][sys-#316%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#316%NODE%xyzGridNodeName% for timeout(ms)=12189
2019-07-04 06:29:03.649[WARN
][sys-#311%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#311%NODE%xyzGridNodeName% for timeout(ms)=11056
2019-07-04 06:29:03.650[WARN
][sys-#295%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#295%NODE%xyzGridNodeName% for timeout(ms)=20848
2019-07-04 06:29:03.649[WARN
][sys-#290%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#290%NODE%xyzGridNodeName% for timeout(ms)=14816
2019-07-04 06:29:03.649[WARN
][sys-#332%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#332%NODE%xyzGridNodeName% for timeout(ms)=14110
2019-07-04 06:29:03.649[WARN
][sys-#298%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#298%NODE%xyzGridNodeName% for timeout(ms)=10028
2019-07-04 06:29:03.650[WARN
][sys-#304%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#304%NODE%xyzGridNodeName% for timeout(ms)=19855
2019-07-04 06:29:03.650[WARN
][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=41277
2019-07-04 06:29:03.650[WARN
][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=17151
2019-07-04 06:29:03.650[WARN
][sys-#308%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#308%NODE%xyzGridNodeName% for timeout(ms)=39312
2019-07-04 06:29:03.650[WARN
][sys-#322%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#322%NODE%xyzGridNodeName% for timeout(ms)=43341
2019-07-04 06:29:03.650[WARN
][sys-#306%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#306%NODE%xyzGridNodeName% for timeout(ms)=21890
2019-07-04 06:29:03.650[WARN
][sys-#315%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#315%NODE%xyzGridNodeName% for timeout(ms)=18909
2019-07-04 06:29:03.650[WARN
][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=74129
2019-07-04 06:29:03.650[WARN
][sys-#305%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#305%NODE%xyzGridNodeName% for timeout(ms)=26608
2019-07-04 06:29:03.650[WARN
][sys-#309%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#309%NODE%xyzGridNodeName% for timeout(ms)=77835
2019-07-04 06:29:03.650[WARN
][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=90104
2019-07-04 06:29:03.650[WARN
][sys-#325%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#325%NODE%xyzGridNodeName% for timeout(ms)=85813
2019-07-04 06:29:03.650[WARN
][sys-#314%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#314%NODE%xyzGridNodeName% for timeout(ms)=81727
2019-07-04 06:29:03.650[WARN
][sys-#338%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#338%NODE%xyzGridNodeName% for timeout(ms)=99340
2019-07-04 06:29:03.650[WARN
][sys-#332%NODE%xyzGridNodeName%][o.a.i.i.p.c.
[jira] [Updated] (IGNITE-12006) Threads may be parked for indefinite time during throttling after spurious wakeups
[
https://issues.apache.org/jira/browse/IGNITE-12006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12006:
Fix Version/s: 2.8
> Threads may be parked for indefinite time during throttling after spurious
> wakeups
> --
>
> Key: IGNITE-12006
> URL: https://issues.apache.org/jira/browse/IGNITE-12006
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> In the log we see the following behavior:
> {noformat}
> 2019-07-04 06:29:03.649[WARN
> ][sys-#328%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#328%NODE%xyzGridNodeName% for timeout(ms)=16335
> 2019-07-04 06:29:03.649[WARN
> ][sys-#326%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#326%NODE%xyzGridNodeName% for timeout(ms)=13438
> 2019-07-04 06:29:03.649[WARN
> ][sys-#277%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#277%NODE%xyzGridNodeName% for timeout(ms)=11609
> 2019-07-04 06:29:03.649[WARN
> ][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=18009
> 2019-07-04 06:29:03.649[WARN
> ][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=15557
> 2019-07-04 06:29:03.650[WARN
> ][sys-#307%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#307%NODE%xyzGridNodeName% for timeout(ms)=27938
> 2019-07-04 06:29:03.649[WARN
> ][sys-#316%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#316%NODE%xyzGridNodeName% for timeout(ms)=12189
> 2019-07-04 06:29:03.649[WARN
> ][sys-#311%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#311%NODE%xyzGridNodeName% for timeout(ms)=11056
> 2019-07-04 06:29:03.650[WARN
> ][sys-#295%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#295%NODE%xyzGridNodeName% for timeout(ms)=20848
> 2019-07-04 06:29:03.649[WARN
> ][sys-#290%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#290%NODE%xyzGridNodeName% for timeout(ms)=14816
> 2019-07-04 06:29:03.649[WARN
> ][sys-#332%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#332%NODE%xyzGridNodeName% for timeout(ms)=14110
> 2019-07-04 06:29:03.649[WARN
> ][sys-#298%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#298%NODE%xyzGridNodeName% for timeout(ms)=10028
> 2019-07-04 06:29:03.650[WARN
> ][sys-#304%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#304%NODE%xyzGridNodeName% for timeout(ms)=19855
> 2019-07-04 06:29:03.650[WARN
> ][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=41277
> 2019-07-04 06:29:03.650[WARN
> ][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=17151
> 2019-07-04 06:29:03.650[WARN
> ][sys-#308%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#308%NODE%xyzGridNodeName% for timeout(ms)=39312
> 2019-07-04 06:29:03.650[WARN
> ][sys-#322%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#322%NODE%xyzGridNodeName% for timeout(ms)=43341
> 2019-07-04 06:29:03.650[WARN
> ][sys-#306%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#306%NODE%xyzGridNodeName% for timeout(ms)=21890
> 2019-07-04 06:29:03.650[WARN
> ][sys-#315%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#315%NODE%xyzGridNodeName% for timeout(ms)=18909
> 2019-07-04 06:29:03.650[WARN
> ][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=74129
> 2019-07-04 06:29:03.650[WARN
> ][sys-#305%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#305%NODE%xyzGridNodeName% for timeout(ms)=26608
> 2019-07-04 06:29:03.650[WARN
> ][sys-#309%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#309%NODE%xyzGridNodeName% for timeout(ms)=77835
> 2019-07-04 06:29:03.650[WARN
> ][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=90104
> 2019-07-04 06:29:03.650[WARN
> ][sys-#325%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl]
> Parking thread=sys-#325%NODE%xyzGridNodeName% for timeo
[jira] [Commented] (IGNITE-12005) AssertionError when put/get byte arrays in cache
[
https://issues.apache.org/jira/browse/IGNITE-12005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890820#comment-16890820
]
Vladimir Pligin commented on IGNITE-12005:
--
This one looks very similar/related to
https://issues.apache.org/jira/browse/IGNITE-11953. [~sboikov], what do you
think?
> AssertionError when put/get byte arrays in cache
>
>
> Key: IGNITE-12005
> URL: https://issues.apache.org/jira/browse/IGNITE-12005
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Semen Boikov
>Priority: Critical
> Attachments: CachePutGetByteArrays.java
>
>
> In attachment test executes puts in cache byte arrays with various sizes
> (among them arrays with size > page size). After this assert fails on
> cache.get:
> {noformat}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1544803905,
> val2=844420635164743]], msg=Runtime failure on lookup row: SearchRow
> [key=org.apache.ignite.internal.processors.cache.distributed.CachePutGetByteArrays$TestKey
> [idHash=209014132, hash=-1084267651, id=9091, dummyData=[0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
