[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-1855:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Alpha5
(was: 7.0.0.Beta1)
Resolution: Done
> Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
> --------------------------------------------------------------------------------------
>
> Key: ISPN-1855
> URL: https://issues.jboss.org/browse/ISPN-1855
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 5.1.1.FINAL
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Alpha5
>
>
> RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode).
> If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches.
> Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-3530) The HotRod client should support a separate CH for each cache
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3530?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3530:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Alpha5
(was: 7.0.0.Beta1)
Resolution: Done
> The HotRod client should support a separate CH for each cache
> -------------------------------------------------------------
>
> Key: ISPN-3530
> URL: https://issues.jboss.org/browse/ISPN-3530
> Project: Infinispan
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 6.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Labels: hotrod, hotrod-java-client
> Fix For: 7.0.0.Alpha5
>
>
> With asymmetric clusters, each cache can have its own consistent hash, so the primary owner of a key in one cache is not necessarily the owner in all the caches. Even with a symmetric cluster, the same client may be used to access both distributed and replicated caches, and those would certainly have a different CH.
> In order to send the operations to the correct owner, the HotRod client should use a different CH for each cache.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4378) Inject marshaller into binary filter/converter instances
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4378?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4378:
-----------------------------------
Fix Version/s: 7.0.0.Final
> Inject marshaller into binary filter/converter instances
> --------------------------------------------------------
>
> Key: ISPN-4378
> URL: https://issues.jboss.org/browse/ISPN-4378
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks.
> Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured.
> There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable.
> However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly.
> Will has done some work with Adrian to make filter/converters cache components and be able to inject stuff in them. Check if that would work for this use case.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4451) Missing ACCESS right
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4451?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-4451:
---------------------------------------
One thing that has changed since the previous release is that you need to invoke globalConfiguration.security().authorization().enable() (enablement was previously implicit).
> Missing ACCESS right
> --------------------
>
> Key: ISPN-4451
> URL: https://issues.jboss.org/browse/ISPN-4451
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
>
> When security is turned on ({{cacheConfig.security().authorization().enable()}}), any user can obtain/create a cache, even unauthorized users. This should be allowed only for users with right {{ACCESS}}. This right is actually not present in {{AuthorizationPermission}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months