[Red Hat JIRA] (ISPN-9165) ManifestUberJarDuplicatedJarsWarner uses FJP without privileged block
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/ISPN-9165?page=com.atlassian.jira.plugin... ]
Boris Unckel updated ISPN-9165:
-------------------------------
Attachment: ManifestUberJarDuplicatedJarsWarner.java
> ManifestUberJarDuplicatedJarsWarner uses FJP without privileged block
> ---------------------------------------------------------------------
>
> Key: ISPN-9165
> URL: https://issues.redhat.com/browse/ISPN-9165
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.2.Final
> Reporter: David Lloyd
> Priority: Critical
> Labels: security-manager
> Attachments: ManifestUberJarDuplicatedJarsWarner.java
>
>
> {{ManifestUberJarDuplicatedJarsWarner}} has a method called {{isClasspathCorrectAsync}} which dispatches a task to the fork-join pool. The task loads resources from the Infinispan JAR.
> This fails under a security manager. The common FJP executes tasks with no permissions. One of two things must be done:
> # Do not use the fork-join pool; find some other async solution which preserves the access control context.
> # Capture and propagate the current AccessControlContext when calling {{isClasspathCorrectAsync}}. This can be done by calling {{AccessController.getContext()}} before submitting the task, and then, within the submitted lambda, wrap the call to isClasspathCorrect with a call to {{AccessController.doPrivileged()}} which restores the captured context (by giving it as the second parameter). Note that this will entail a nested lambda or anonymous class.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[Red Hat JIRA] (ISPN-12564) Remove support for property "infinispan.query.lucene.max-boolean-clauses" from the index config
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12564?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12564:
-------------------------------------
Description:
The Lucene max Clauses is a JVM level (static config) and affects all caches, so it doesn't make sense to have:
{code:java}
builder.indexing().enable()
.storage(LOCAL_HEAP)
.addIndexedEntity("sample_bank_account.User")
.addProperty("infinispan.query.lucene.max-boolean-clauses", "1025");
{code}
was:
This config is a JVM level config and affects all caches, so it doesn't make sense to have:
{code:java}
builder.indexing().enable()
.storage(LOCAL_HEAP)
.addIndexedEntity("sample_bank_account.User")
.addProperty("infinispan.query.lucene.max-boolean-clauses", "1025");
{code}
> Remove support for property "infinispan.query.lucene.max-boolean-clauses" from the index config
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-12564
> URL: https://issues.redhat.com/browse/ISPN-12564
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
> Priority: Major
>
> The Lucene max Clauses is a JVM level (static config) and affects all caches, so it doesn't make sense to have:
> {code:java}
> builder.indexing().enable()
> .storage(LOCAL_HEAP)
> .addIndexedEntity("sample_bank_account.User")
> .addProperty("infinispan.query.lucene.max-boolean-clauses", "1025");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months
[Red Hat JIRA] (ISPN-12477) Remove IRAC sender thread
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-12477?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-12477:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Remove IRAC sender thread
> -------------------------
>
> Key: ISPN-12477
> URL: https://issues.redhat.com/browse/ISPN-12477
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 12.0.0.Dev05
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> We have a dedicated thread in the background sending the updates to the remote site. We can get rid of it and use the blocking thread pool to send the update.
> Also, based on the last discussion, don't send the keys in batches. Just do continuous sending and let the Flow Control in JGroups manages the network.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 6 months