<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 25, 2014 at 10:21 PM, Tristan Tarrant <span dir="ltr">&lt;<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 12/08/14 22:41, Dan Berindei wrote:<br>
&gt;<br>
&gt; I like the idea of shipping the cache configuration to all the nodes.<br>
&gt; We will have to require any user-provided objects in the configuration<br>
&gt; to be serializable/externalizable, but I don&#39;t see a big problem with<br>
&gt; that.<br>
&gt;<br>
&gt; In fact, it would also allow us to send the entire configuration to<br>
&gt; the coordinator on join, so we could verify that the configuration on<br>
&gt; all nodes is compatible (not exactly the same, since things like<br>
&gt; capacityFactor can be different). And it would remove the need for the<br>
&gt; CacheJoinInfo class...<br>
</div>Can&#39;t we store the configuration defs in the cluster registry ? If a<br>
node attempts to overwrite an existing configuration based on the same<br>
name, an exception can be thrown.<br></blockquote><div><br></div><div>The cluster registry also uses a clustered cache, how would we ship the cache configuration around for that cache?<br></div><div><br></div><div>The cluster registry is also too limited to do this check ATM, as it doesn&#39;t support conditional operations. I&#39;m not sure whether that&#39;s because they just weren&#39;t needed, or it&#39;s an intentional limitation.<br>

</div><div><br></div><div>Cheers</div><div>Dan</div><div><br></div></div></div></div>