[jira] [Created] (IGNITE-12005) AssertionError when put/get byte arrays in cache
Semen Boikov created IGNITE-12005:
-
Summary: 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
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, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 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] [Created] (IGNITE-12004) CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky
Ivan Pavlukhin created IGNITE-12004: --- Summary: CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky Key: IGNITE-12004 URL: https://issues.apache.org/jira/browse/IGNITE-12004 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.7.5 Reporter: Ivan Pavlukhin Assignee: Ivan Pavlukhin CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields fails often https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4227647830422954979&tab=testDetails -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12003:
Description:
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact
footer: " + typeId)}}.
See attached reproducer.
was:
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact
footer: " + typeId)}}.
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12003:
Attachment: ThinClientCompactFooterDeserializationProblem.java
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
Ivan Pavlukhin created IGNITE-12003:
---
Summary: Java thin client fails to get object with compact footer
from cache
Key: IGNITE-12003
URL: https://issues.apache.org/jira/browse/IGNITE-12003
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.7.5
Reporter: Ivan Pavlukhin
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact
footer: " + typeId)}}.
--
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=16890118#comment-16890118 ] Ivan Pavlukhin commented on IGNITE-12002: - [~panes], it seems that similar problem was fixed in IGNITE-11438. It would be great to check your reproducer against master branch. > [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] [Updated] (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:all-tabpanel ] Philippe Anes updated IGNITE-12002: --- Description: 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) was: 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 issues described on top. (Global setup: Writing 10k entries of 64octets each with TTL 10s) > [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] [Created] (IGNITE-12002) [TTL] Some expired data remains in memory even with eager TTL enabled
Philippe Anes created IGNITE-12002: -- Summary: [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 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 issues 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] [Updated] (IGNITE-11410) Security Engine fixes and test coverage. Phase #2.
[ https://issues.apache.org/jira/browse/IGNITE-11410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-11410: - Description: 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). was: 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 sense 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). > Security Engine fixes and test coverage. Phase #2. > -- > > 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] [Updated] (IGNITE-11410) Security Engine fixes and test coverage. Phase #2.
[ https://issues.apache.org/jira/browse/IGNITE-11410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-11410: - Description: 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 sense 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). was: 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 sense 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). > Security Engine fixes and test coverage. Phase #2. > -- > > 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 sense 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] [Updated] (IGNITE-11410) Security Engine fixes and test coverage. Phase #2.
[ https://issues.apache.org/jira/browse/IGNITE-11410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-11410: - Description: 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 sense 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). was:TBD > Security Engine fixes and test coverage. Phase #2. > -- > > 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 sense 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-3195) Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
[
https://issues.apache.org/jira/browse/IGNITE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890034#comment-16890034
]
Maxim Muzafarov commented on IGNITE-3195:
-
[~avinogradov]
Sure, I will take a look, shortly!
> Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
> ---
>
> Key: IGNITE-3195
> URL: https://issues.apache.org/jira/browse/IGNITE-3195
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-16
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Presently it's considered that the maximum number of threads that has to
> process all demand and supply messages coming from all the nodes must not be
> bigger than {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> Current implementation relies on ordered messages functionality creating a
> number of topics equal to {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> However, the implementation doesn't take into account that ordered messages,
> that correspond to a particular topic, are processed in parallel for
> different nodes. Refer to the implementation of
> {{GridIoManager.processOrderedMessage}} to see that for every topic there
> will be a unique {{GridCommunicationMessageSet}} for every node.
> Also to prove that this is true you can refer to this execution stack
> {noformat}
> java.lang.RuntimeException: HAPPENED DEMAND
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:81)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2456)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1179)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1148)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> All this means that in fact the number of threads that will be busy with
> replication activity will be equal to
> {{IgniteConfiguration.rebalanceThreadPoolSize}} x
> number_of_nodes_participated_in_rebalancing
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
