On Tue, Oct 29, 2013 at 12:58 PM, Dan Berindei wrote:
>
>
>
> On Tue, Oct 29, 2013 at 3:56 PM, Mircea Markus wrote:
>>
>>
>> On Oct 29, 2013, at 3:08 PM, William Burns wrote:
>>
>> > I agree, and I could have sworn there was a JIRA that detailed this,
>> > but I can't seem to locate it now. I w
On Tue, Oct 29, 2013 at 3:56 PM, Mircea Markus wrote:
>
> On Oct 29, 2013, at 3:08 PM, William Burns wrote:
>
> > I agree, and I could have sworn there was a JIRA that detailed this,
> > but I can't seem to locate it now. I was hoping to get to it next
> > release.
>
> +1.
>
> >
> > This also i
On Oct 29, 2013, at 3:08 PM, William Burns wrote:
> I agree, and I could have sworn there was a JIRA that detailed this,
> but I can't seem to locate it now. I was hoping to get to it next
> release.
+1.
>
> This also is a very big improvement for non tx caches as well as the
> updating cach
I agree, and I could have sworn there was a JIRA that detailed this,
but I can't seem to locate it now. I was hoping to get to it next
release.
This also is a very big improvement for non tx caches as well as the
updating cache only has to send a single message, possibly reducing
the overall amou
Hi,
Pedro suggested moving the following idea to separate thread (from the
'Improve WriteCommand processing code...'). Re:
I've been wondering for a while why the fetch part is a separate message
in the write flow. Is the return value of much use when it does not
return really the replaced val
