[infinispan-dev] On the scattered cache blog post

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] On the scattered cache blog post

Galder Zamarreño
Hey Radim,

Awesome blog post on scattered cache [1]!

I think there's some extra information to be added or to be clarified in the blog itself:

1. From what I understand, scattered cache should help the embedded use case primarily? When using Hot Rod, the primary owner is always hit, so the penalty of landing in a non-owner and having to do 2 RPCs is not there. Am I right? This should be clarified in the blog post.

2. "As you can see, this algorithm cannot be easily extended to multiple owners" <- Do you mean users should never set num owners to 3 or higher? How would the system work if num owners was 1?

Some of these questions might have been answered in the design doc, but as a user, I should not be expected to read the design document to answer these questions.

If these questions are answered in the user documentation, that would be fine but I feel these are things that should be explained/clarified in the blog post itself.

Cheers,

[1] http://blog.infinispan.org/2017/07/scattered-cache.html
--
Galder Zamarreño
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] On the scattered cache blog post

Radim Vansa
Hi Galder,

1. Yes, and the documentation states that we do not support scattered cache in server, see the last paragraph:

> Scattered mode is not exposed in the server configuration as the server is usually accessed through the Hot Rod protocol. The protocol automatically selects primary owner for the writes and therefore the write (in distributed mode with two owner) requires single RPC inside the cluster, too. Therefore, scattered cache would not bring the performance benefit.

In the blogpost I have focused on 'what works' and on the design. I've left the limitations (server, functional commands) for the documentation, keeping it short. If you really thing that I should mention server, I could do that...

2. Setting numOwners to anything but 1 (or keeping it at default value) throws an exception when the configuration is validated. XML does not expose such attribute. Yes, you've read correctly: 1 is the num owners because we don't keep more owners in the CH, so it's resilient against one node failure with single owner. I could add this info to the user docs.

Radim


On Tue, Jul 4, 2017 at 1:11 PM, Galder Zamarreño <[hidden email]> wrote:
Hey Radim,

Awesome blog post on scattered cache [1]!

I think there's some extra information to be added or to be clarified in the blog itself:

1. From what I understand, scattered cache should help the embedded use case primarily? When using Hot Rod, the primary owner is always hit, so the penalty of landing in a non-owner and having to do 2 RPCs is not there. Am I right? This should be clarified in the blog post.

2. "As you can see, this algorithm cannot be easily extended to multiple owners" <- Do you mean users should never set num owners to 3 or higher? How would the system work if num owners was 1?

Some of these questions might have been answered in the design doc, but as a user, I should not be expected to read the design document to answer these questions.

If these questions are answered in the user documentation, that would be fine but I feel these are things that should be explained/clarified in the blog post itself.

Cheers,

[1] http://blog.infinispan.org/2017/07/scattered-cache.html
--
Galder Zamarreño
Infinispan, Red Hat




--
Radim Vansa
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] On the scattered cache blog post

Emmanuel Bernard
On Tue 17-07-04 13:21, Radim Vansa wrote:
>2. Setting numOwners to anything but 1 (or keeping it at default value)
>throws an exception when the configuration is validated. XML does not
>expose such attribute. Yes, you've read correctly: 1 is the num owners
>because we don't keep more owners in the CH, so it's resilient against one
>node failure with single owner. I could add this info to the user docs.

I must be missing something but if you are only resilient when < 1 node
goes down, aren't you called a non resilient system?
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...