<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/13/2014 03:58 PM, Dan Berindei
wrote:<br>
</div>
<blockquote
cite="mid:CA+nfvwQDkzbZ7fuoLX80xtx0KgspGZVWoqD+vo=W5iFRSCcKEg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, May 12, 2014 at 1:54 PM,
Radim Vansa <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">@Dan:
It's absolutely correct to do the further writes in order
to make<br>
the cache consistent, I am not arguing against that.
You've fixed the<br>
outcome (state of cache) well. My point was that we should
let the user<br>
know that the value he gets is not 100% correct when we
already know<br>
that - and given the API, the only option to do that seems
to me as<br>
throwing an exception.<br>
</blockquote>
<div><br>
</div>
<div>The problem, as I see it, is that users also expect
methods that throw an exception to *not* modify the cache.</div>
<div>So we would break some of the users' expectations
anyway.</div>
</div>
</div>
</div>
</blockquote>
<br>
When the response from primary owner does not arrive soon, we throw
timeout exception and the cache is modified anyway, isn't it?<br>
If we throw ~ReturnValueUnreliableException, the user has at least
some chance to react. Currently, for code requiring 100% reliable
value, you can't do anything but ignore the return value, even for
CAS operations.<br>
<br>
<blockquote
cite="mid:CA+nfvwQDkzbZ7fuoLX80xtx0KgspGZVWoqD+vo=W5iFRSCcKEg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
@Sanne: I was not suggesting that for now - sure, value
versioning is (I<br>
hope) on the roadmap. But that's more complicated, I
though just about<br>
making an adjustment to the current implementation.<br>
</blockquote>
<div><br>
</div>
<div><br class="">
Actually, just keeping a history of values would not fix
the the return value in all cases.</div>
<div><br>
</div>
<div>When retrying a put on the new primary owner, the
primary owner would still have to compare our value with
the latest value, and return the previous value if they
are equal. So we could have something like this:</div>
<div><br>
</div>
<div>A is the originator, B is the primary owner, k = v0</div>
<div>A -> B: put(k, v1)</div>
<div>B dies before writing v, C is now primary owner</div>
<div>D -> C: put(k, v1) // another put operation from D,
with the same value</div>
<div>C -> D: null</div>
<div>A -> C: retry_put(k, v1)</div>
<div>C -> A: v0 // C assumes A is overwriting its own
value, so it's returning the previous one</div>
<div><br>
</div>
<div>To fix that, we'd need a unique version generated by
the originator - kind of like a transaction id ;)</div>
</div>
</div>
</div>
</blockquote>
<br>
Is it such a problem to associate unique ID with each write? History
implementation seems to me like the more complicated part.<br>
<br>
<blockquote
cite="mid:CA+nfvwQDkzbZ7fuoLX80xtx0KgspGZVWoqD+vo=W5iFRSCcKEg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>And to fix the HotRod use case, the HotRod client would
have to be the one generating the version.</div>
</div>
</div>
</div>
</blockquote>
<br>
I agree.<br>
<br>
Radim<br>
<br>
<blockquote
cite="mid:CA+nfvwQDkzbZ7fuoLX80xtx0KgspGZVWoqD+vo=W5iFRSCcKEg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Cheers</div>
<div>Dan</div>
<div> </div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
class=""><font color="#888888">
Radim<br>
</font></span>
<div class="">
<div class="h5"><br>
On 05/12/2014 12:02 PM, Sanne Grinovero wrote:<br>
> I don't think we are in a position to decide what
is a reasonable<br>
> compromise; we can do better.<br>
> For example - as Radim suggested - it might seem
reasonable to have<br>
> the older value around for a little while. We'll
need a little bit of<br>
> history of values and tombstones anyway for many
other reasons.<br>
><br>
><br>
> Sanne<br>
><br>
> On 12 May 2014 09:37, Dan Berindei <<a
moz-do-not-send="true"
href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>>
wrote:<br>
>> Radim, I would contend that the first and
foremost guarantee that put()<br>
>> makes is to leave the cache in a consistent
state. So we can't just throw an<br>
>> exception and give up, leaving k=v on one
owner and k=null on another.<br>
>><br>
>> Secondly, put(k, v) being atomic means that
it either succeeds, it writes<br>
>> k=v in the cache, and it returns the previous
value, or it doesn't succeed,<br>
>> and it doesn't write k=v in the cache.
Returning the wrong previous value is<br>
>> bad, but leaving k=v in the cache is just as
bad, even if the all the owners<br>
>> have the same value.<br>
>><br>
>> And last, we can't have one node seeing
k=null, then k=v, then k=null again,<br>
>> when the only write we did on the cache was a
put(k, v). So trying to undo<br>
>> the write would not help.<br>
>><br>
>> In the end, we have to make a compromise, and
I think returning the wrong<br>
>> value in some of the cases is a reasonable
compromise. Of course, we should<br>
>> document that :)<br>
>><br>
>> I also believe ISPN-2956 could be fixed so
that HotRod behaves just like<br>
>> embedded mode after the ISPN-3422 fix, by
adding a RETRY flag to the HotRod<br>
>> protocol and to the cache itself.<br>
>><br>
>> Incidentally, transactional caches have a
similar problem when the<br>
>> originator leaves the cluster: ISPN-3421 [1]<br>
>> And we can't handle transactional caches any
better than non-transactional<br>
>> caches until we expose transactions to the
HotRod client.<br>
>><br>
>> [1] <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/ISPN-2956"
target="_blank">https://issues.jboss.org/browse/ISPN-2956</a><br>
>><br>
>> Cheers<br>
>> Dan<br>
>><br>
>><br>
>><br>
>><br>
>> On Mon, May 12, 2014 at 10:21 AM, Radim Vansa
<<a moz-do-not-send="true"
href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>>
wrote:<br>
>>> Hi,<br>
>>><br>
>>> recently I've stumbled upon one already
expected behaviour (one instance<br>
>>> is [1]), but which did not got much
attention.<br>
>>><br>
>>> In non-tx cache, when the primary owner
fails after the request has been<br>
>>> replicated to backup owner, the request
is retried in the new topology.<br>
>>> Then, the operation is executed on the
new primary (the previous<br>
>>> backup). The outcome has been already
fixed in [2], but the return value<br>
>>> may be wrong. For example, when we do a
put, the return value for the<br>
>>> second attempt will be the currently
inserted value (although the entry<br>
>>> was just created). Same situation may
happen for other operations.<br>
>>><br>
>>> Currently, it's not possible to return
the correct value (because it has<br>
>>> already been overwritten and we don't
keep a history of values), but<br>
>>> shouldn't we rather throw an exception if
we were not able to fulfil the<br>
>>> API contract?<br>
>>><br>
>>> Radim<br>
>>><br>
>>> [1] <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/ISPN-2956"
target="_blank">https://issues.jboss.org/browse/ISPN-2956</a><br>
>>> [2] <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/ISPN-3422"
target="_blank">https://issues.jboss.org/browse/ISPN-3422</a><br>
>>><br>
>>> --<br>
>>> Radim Vansa <<a moz-do-not-send="true"
href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>><br>
>>> JBoss DataGrid QA<br>
>>><br>
>>>
_______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/infinispan-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
>><br>
>>
_______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/infinispan-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/infinispan-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
--<br>
Radim Vansa <<a moz-do-not-send="true"
href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>><br>
JBoss DataGrid QA<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/infinispan-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Radim Vansa <a class="moz-txt-link-rfc2396E" href="mailto:rvansa@redhat.com"><rvansa@redhat.com></a>
JBoss DataGrid QA
</pre>
</body>
</html>