<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <span dir="ltr"><<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>>>> 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>
</div>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></blockquote><div><br></div><div>A couple more differences:<br></div><div>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>
</div><div>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></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><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>
</div>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></blockquote><div><br></div><div>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></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><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>
</div>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>
<span class="HOEnZb"><font color="#888888"><br>
Radim<br>
</font></span><div class="im HOEnZb"><br>
--<br>
Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>><br>
JBoss DataGrid QA<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div></div>