[Red Hat JIRA] (ISPN-12594) Exception for embedded cache Iteration if partition handling is configured
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-12594?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-12594:
------------------------------
Fix Version/s: 12.0.0.Final
Assignee: Dan Berindei
Resolution: Done
Status: Resolved (was: Pull Request Sent)
> Exception for embedded cache Iteration if partition handling is configured
> --------------------------------------------------------------------------
>
> Key: ISPN-12594
> URL: https://issues.redhat.com/browse/ISPN-12594
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Partition Handling
> Affects Versions: 12.0.0.Dev07
> Reporter: Wolf-Dieter Fink
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 12.0.0.Final
>
> Attachments: IterationTest.zip
>
>
> No matter whether streams are used or not the Iteration with values() keySet() entrySet() throws the following Exception
> org.infinispan.commons.CacheException: io.reactivex.rxjava3.exceptions.MissingBackpressureException: Could not emit value due to lack of requests
> at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:686)
> at org.infinispan.commons.reactive.RxJavaInterop.lambda$static$2(RxJavaInterop.java:47)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableOnErrorNext$OnErrorNextSubscriber.onError(FlowableOnErrorNext.java:94)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableDoOnEach$DoOnEachSubscriber.onError(FlowableDoOnEach.java:111)
> at io.reactivex.rxjava3.processors.PublishProcessor$PublishSubscription.onNext(PublishProcessor.java:367)
> at io.reactivex.rxjava3.processors.PublishProcessor.onNext(PublishProcessor.java:242)
> at io.reactivex.rxjava3.processors.SerializedProcessor.onNext(SerializedProcessor.java:103)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableRepeatUntil$RepeatSubscriber.onNext(FlowableRepeatUntil.java:67)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableDoOnLifecycle$SubscriptionLambdaSubscriber.onNext(FlowableDoOnLifecycle.java:79)
> at io.reactivex.rxjava3.processors.UnicastProcessor.drainRegular(UnicastProcessor.java:309)
> at io.reactivex.rxjava3.processors.UnicastProcessor.drain(UnicastProcessor.java:384)
> at io.reactivex.rxjava3.processors.UnicastProcessor.subscribeActual(UnicastProcessor.java:486)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15750)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableDoOnLifecycle.subscribeActual(FlowableDoOnLifecycle.java:38)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15750)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15696)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableScalarXMap$ScalarXMapFlowable.subscribeActual(FlowableScalarXMap.java:160)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15750)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15696)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableScalarXMap$ScalarXMapFlowable.subscribeActual(FlowableScalarXMap.java:160)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15750)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15696)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableRepeatUntil$RepeatSubscriber.subscribeNext(FlowableRepeatUntil.java:109)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableRepeatUntil.subscribeActual(FlowableRepeatUntil.java:38)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15750)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15696)
> at org.infinispan.reactive.publisher.impl.ClusterPublisherManagerImpl$SubscriberHandler.start(ClusterPublisherManagerImpl.java:973)
> at org.infinispan.reactive.publisher.impl.ClusterPublisherManagerImpl$AbstractSegmentAwarePublisher.subscribe(ClusterPublisherManagerImpl.java:1170)
> at org.infinispan.reactive.publisher.impl.PartitionAwareClusterPublisherManager.lambda$registerPublisher$2(PartitionAwareClusterPublisherManager.java:144)
> at org.infinispan.reactive.publisher.impl.SegmentCompletionPublisher.subscribe(SegmentCompletionPublisher.java:34)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableFromPublisher.subscribeActual(FlowableFromPublisher.java:29)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15750)
> at io.reactivex.rxjava3.internal.operators.flowable.FlowableOnErrorNext.subscribeActual(FlowableOnErrorNext.java:39)
> at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15750)
> at io.reactivex.rxjava3.internal.operators.flowable.BlockingFlowableIterable.iterator(BlockingFlowableIterable.java:42)
> at org.infinispan.commons.util.Closeables.iterator(Closeables.java:238)
> at org.infinispan.util.Closeables.iterator(Closeables.java:26)
> at org.infinispan.stream.impl.DistributedCacheStream.iterator(DistributedCacheStream.java:376)
> at org.infinispan.commons.util.Closeables.iterator(Closeables.java:73)
> at org.infinispan.interceptors.distribution.DistributionBulkInterceptor$BackingEntrySet.iterator(DistributionBulkInterceptor.java:80)
> at org.infinispan.interceptors.distribution.DistributionBulkInterceptor$BackingEntrySet.iterator(DistributionBulkInterceptor.java:67)
> at org.infinispan.util.WriteableCacheCollectionMapper.iterator(WriteableCacheCollectionMapper.java:60)
> at org.infinispan.wfink.clustered.ClusteredIterationStandalone.loop2(ClusteredIterationStandalone.java:83)
> at org.infinispan.wfink.clustered.ClusteredIterationStandalone.main(ClusteredIterationStandalone.java:136)
> Caused by: io.reactivex.rxjava3.exceptions.MissingBackpressureException: Could not emit value due to lack of requests
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (ISPN-12620) Implicit authorization
by Tristan Tarrant (Jira)
Tristan Tarrant created ISPN-12620:
--------------------------------------
Summary: Implicit authorization
Key: ISPN-12620
URL: https://issues.redhat.com/browse/ISPN-12620
Project: Infinispan
Issue Type: Enhancement
Components: Security, Server
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 13.0.0.Final
Authorization should be enabled OOTB in the server.
* out-of-the-box, authorization would apply only at the cache manager level. Caches would not have authz enabled by default (the performance cost is non-negligible)
* the current small set of permissions which can be combined to form roles is not flexible enough. We would need to have named roles, possibly mapping to the REST resource names (e.g. {{/v2/logging/loggers, /v2/caches/cacheName}}) and map permissions to verbs ({{GET/HEAD = READ, POST,PUT,DELETE = WRITE}}). We might want to use resource prefixes to provide coarser management
* users upgrading from older versions will need to add the roles to their existing users.
To make use of authorization less cumbersome we should also have some defaults.
Adding the empty {{<authorization>}} element should enable authorization with a set of default predefined roles
A proposed list of these roles:
* admin superuser, allowed to do everything
* application allowed to perform all read/write ops, but not allowed to create/remove caches, schemas, scripts
* deployer allowed to create/remove caches, schemas, scripts
* observer a read-only role. Can use the CLI/console but all write ops are forbidden
In terms of {{org.infinispan.security.AuthorizationPermission}} add the following permission:
CREATE which would allow create/remove of caches, counters, schemas, scripts
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (ISPN-12616) Rolling Upgrade fails for caches storing POJOs
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12616?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12616:
-------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/8978
Status: Pull Request Sent (was: Coding In Progress)
> Rolling Upgrade fails for caches storing POJOs
> ----------------------------------------------
>
> Key: ISPN-12616
> URL: https://issues.redhat.com/browse/ISPN-12616
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod, Loaders and Stores
> Affects Versions: 12.0.0.CR1, 11.0.8.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> The Remote Store does not support transcoding yet, and the data conversions are done implicitly by combining the 'hotRodWrapping', 'marshaller' and 'rawValues' configurations.
> The rolling upgrade process forces the remote store to use 'hotRodWrapping', that prevents consuming a cache that stores "application/x-java-objects", since it assumes the data is already in "application/x-jboss-marshalling" format, causing lots of internal issues.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (ISPN-12619) Support for Rolling Upgrade in embedded caches
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPN-12619:
----------------------------------------
Summary: Support for Rolling Upgrade in embedded caches
Key: ISPN-12619
URL: https://issues.redhat.com/browse/ISPN-12619
Project: Infinispan
Issue Type: Bug
Components: Hot Rod, Loaders and Stores
Affects Versions: 12.0.0.CR1, 11.0.8.Final
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
The Remote Store does not support transcoding yet, and the data conversions are done implicitly by combining the 'hotRodWrapping', 'marshaller' and 'rawValues' configurations.
The rolling upgrade process forces the remote store to use 'hotRodWrapping', that prevents consuming a cache that stores "application/x-java-objects", since it assumes the data is already in "application/x-jboss-marshalling" format, causing lots of internal issues.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (ISPN-12607) Metrics degrade cluster performance
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12607?page=com.atlassian.jira.plugi... ]
Ryan Emerson reassigned ISPN-12607:
-----------------------------------
Assignee: Ryan Emerson
> Metrics degrade cluster performance
> -----------------------------------
>
> Key: ISPN-12607
> URL: https://issues.redhat.com/browse/ISPN-12607
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 12.0.0.CR1, 11.0.8.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> The `/metrics` endpoint exposes Infinispan stats so that they can be periodically scraped by monitoring tools such as Prometheus. However, these stats include calls to `size` which does not perform well as the number of entries in a cache increase. Consequently, if deploying DG in a k8 environment with Prometheus monitoring the DG cluster performance rapidly declines as the number of entries in a cache increases due to time /resources spent iterating the cache container.
> This problem is only exasperated when muiltiple caches exist with many entries exist.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (ISPN-12618) Configuration/Serialization refactoring
by Tristan Tarrant (Jira)
Tristan Tarrant created ISPN-12618:
--------------------------------------
Summary: Configuration/Serialization refactoring
Key: ISPN-12618
URL: https://issues.redhat.com/browse/ISPN-12618
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 13.0.0.Final
Currently Infinispan's configuration parsers and serializers rely on {{XmlStreamReader}} and {{XmlStreamWriter}} from {{java.xml}} directly. This means that supporting other formats (JSON, YAML) requires writing parallel implementations.
Additionally, referencing {{java.xml}} pulls in 200 classes which have an RSS impact of about 20MB.
We should refactor the parsing/serialization code so that it can support multiple formats.
The [XPP3|https://www.extreme.indiana.edu/xgws/xsoap/xpp/] implementation is very compact and doesn't rely on the internal {{java.xml}} classes.
Identify other modules which may pull in XML classes and try to avoid that.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (ISPN-12617) Transport security
by Tristan Tarrant (Jira)
Tristan Tarrant created ISPN-12617:
--------------------------------------
Summary: Transport security
Key: ISPN-12617
URL: https://issues.redhat.com/browse/ISPN-12617
Project: Infinispan
Issue Type: Feature Request
Components: Security, Server
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 13.0.0.Final
Extend the {{infinispan/cache-container/transport}} schema so that a {{security-realm}} may be specified in server configurations:
{code:xml}
<cache-container name="default">
<transport cluster="${infinispan.cluster.name:cluster}" stack="${infinispan.cluster.stack:tcp}" node-name="${infinispan.node.name:}" server:security-realm="default"/>
</cache-container>
{code}
If the security realm has an SSL server identity, JGroups will be configured to use a {{SSLSocketFactory}}.
If the security realm has a backing realm, JGroups will be configured to enable authentication.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (ISPN-12616) Rolling Upgrade fails for caches storing POJOs
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12616?page=com.atlassian.jira.plugi... ]
Work on ISPN-12616 started by Gustavo Fernandes.
------------------------------------------------
> Rolling Upgrade fails for caches storing POJOs
> ----------------------------------------------
>
> Key: ISPN-12616
> URL: https://issues.redhat.com/browse/ISPN-12616
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod, Loaders and Stores
> Affects Versions: 12.0.0.CR1, 11.0.8.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> The Remote Store does not support transcoding yet, and the data conversions are done implicitly by combining the 'hotRodWrapping', 'marshaller' and 'rawValues' configurations.
> The rolling upgrade process forces the remote store to use 'hotRodWrapping', that prevents consuming a cache that stores "application/x-java-objects", since it assumes the data is already in "application/x-jboss-marshalling" format, causing lots of internal issues.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months