<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 1:03 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 19 February 2014 07:12, Galder Zamarreņo <<a href="mailto:galder@redhat.com">galder@redhat.com</a>> wrote:<br>
><br>
> On 03 Feb 2014, at 19:01, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
><br>
>><br>
>><br>
>><br>
>> On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>> wrote:<br>
>> >>>> For sync we would want to invoke directly to avoid context switching.<br>
>> >>> I think you haven't properly understood what I was talking about: the<br>
>> >>> putAsync should not switch context at all in the ideal design. It should<br>
>> >>> traverse through the interceptors all the way down (logically, in<br>
>> >>> current behaviour), invoke JGroups async API and jump out. Then, as soon<br>
>> >>> as the response is received, the thread which delivered it should<br>
>> >>> traverse the interceptor stack up (again, logically), and fire the future.<br>
>> > A Future doesn't make much sense with an async transport. The problem<br>
>> > is with an async transport you never get back a response so you never<br>
>> > know when the actual command is completed and thus a Future is<br>
>> > worthless. The caller wouldn't know if they could rely on the use of<br>
>> > the Future or not.<br>
>><br>
>> You're right, there's one important difference between putAsync and put<br>
>> with async transport: in the first case you can find out when the<br>
>> request is completed while you cannot with the latter. Not requiring the<br>
>> ack can be an important optimization. I think that both versions are<br>
>> very valid: first mostly for bulk operations = reduction of latency,<br>
>> second for modifications that are acceptable to fail without handling that.<br>
>> I had the first case in my mind when talking about async operations, and<br>
>> there the futures are necessary.<br>
>><br>
>> A couple more differences:<br>
>> 1. You can't do commitAsync(), but you can configure the commit to be replicated asynchronously (1PC). Although we did talk about removing that option...<br>
>> 2. If you do putAsync(k, v1); putAsync(k, v2), there is no ordering between the two and you might end up with k=v1 in the cache.<br>
><br>
> If there’s any relationship between both puts for the caller thread, the caller must make sure that the second put is only called after the first has completed.<br>
<br>
</div></div>Actually in such a case I would strongly expect Infinispan to keep the<br>
two operations in order. This is not to be pushed on user's<br>
responsibility.<br></blockquote><div><br></div><div>I think you're talking about some other kind of putAsync(k, v) than we have now... all the work in putAsync happens on a separate thread, so there is no ordering between two separate putAsync calls whatsoever.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
><br>
> If there’s separate threads calling it and it relies on this, it should call replace the second time, i.e. replaceAsync(k, v1, v2) to get the guarantees it wants.<br>
><br>
> What is really important is that the order in which they are executed in one node/replica is the same order in which they’re executed in all other nodes. This was something that was not maintained when async marshalling was enabled.<br>
<br>
</div>+1000<br>
<br>
But also I'd stress that any sync operation should have a Future<br>
returned, someone in this long thread suggested to have an option to<br>
drop it for example to speedup bulk imports, but I really can't see a<br>
scenario in which I wouldn't want to know about a failure. Let's not<br>
do the same mistake that made MongoDB so "popular" ;-)<br>
Bulk imports can still be mad efficient without strictly needing to go<br>
these lenghts.<br></blockquote><div><br></div><div>You mean if the operation is synchronous, but the cache store/replication is async? I don't see how sync operations could return a Future, since most of them already have a return value. <br>
<br>Bulk imports could certainly use putAsync(k, v), and that would indeed return a Future.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Sanne<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
>><br>
>><br>
>> ><br>
>> > Also it depends what you are trying to do with async. Currently async<br>
>> > transport is only for sending messages to another node, we never think<br>
>> > of when we are the owning node. In this case the calling thread would<br>
>> > have to go down the interceptor stack and acquire any locks if it is<br>
>> > the owner, thus causing this "async" to block if you have any<br>
>> > contention on the given key. The use of another thread would allow<br>
>> > the calling thread to be able to return immediately no matter what<br>
>> > else is occurring. Also I don't see what is so wrong about having a<br>
>> > context switch to run something asynchronously, we shouldn't have a<br>
>> > context switch to block the user thread imo, which is very possible<br>
>> > with locking.<br>
>><br>
>> This is an important notice! Locking would complicate the design a lot,<br>
>> because the thread in "async" mode should do only tryLocks - if this<br>
>> fails, further processing should be dispatched to another thread. Not<br>
>> sure if this could be implemented at all, because the thread may be<br>
>> blocked inside JGroups as well (async API is about receiving the<br>
>> response asynchronously, not about sending the message asynchronously).<br>
>><br>
>> I don't say that the context switch is that bad. My concern is that you<br>
>> have a very limited amount of requests that can be processed in<br>
>> parallel. I consider a "request" something pretty lightweight in concept<br>
>> - but one thread per request makes this rather heavyweight stuff.<br>
>><br>
>> We did talk in Farnborough/Palma about removing the current LockManager with a queue-based structure like the one used for ordering total-order transactions. And about removing the implicit stack in the current interceptor stack with an explicit stack, to allow resuming a command mid-execution. But the feeling I got was that neither is going to make it into 7.0.<br>
>><br>
>><br>
>> ><br>
>> >> +1 much cleaner, I love it. Actually wasn't aware the current code<br>
>> >> didn't do this :-(<br>
>> > This is what the current async transport does, but it does nothing with Futures.<br>
>><br>
>> Nevermind the futures, this is not the important part. It's not about<br>
>> async transport neither, it's about async executors.<br>
>> (okay, the thread was about dropping async transport, I have hijacked it)<br>
>><br>
>> Radim<br>
>><br>
>> --<br>
>> Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>><br>
>> JBoss DataGrid QA<br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
><br>
> --<br>
> Galder Zamarreņo<br>
> <a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
> <a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
><br>
> Project Lead, Escalante<br>
> <a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
><br>
> Engineer, Infinispan<br>
> <a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></div></div></blockquote></div><br></div></div>