On Wed, Feb 19, 2014 at 1:03 PM, Sanne Grinovero <sanne(a)infinispan.org>wrote:
On 19 February 2014 07:12, Galder Zamarreño <galder(a)redhat.com>
wrote:
>
> On 03 Feb 2014, at 19:01, Dan Berindei <dan.berindei(a)gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <rvansa(a)redhat.com> wrote:
>> >>>> For sync we would want to invoke directly to avoid context
switching.
>> >>> I think you haven't properly understood what I was talking
about:
the
>> >>> putAsync should not switch context at all in the ideal design. It
should
>> >>> traverse through the interceptors all the way down (logically, in
>> >>> current behaviour), invoke JGroups async API and jump out. Then,
as
soon
>> >>> as the response is received, the thread which delivered it should
>> >>> traverse the interceptor stack up (again, logically), and fire the
future.
>> > A Future doesn't make much sense with an async transport. The problem
>> > is with an async transport you never get back a response so you never
>> > know when the actual command is completed and thus a Future is
>> > worthless. The caller wouldn't know if they could rely on the use of
>> > the Future or not.
>>
>> You're right, there's one important difference between putAsync and put
>> with async transport: in the first case you can find out when the
>> request is completed while you cannot with the latter. Not requiring the
>> ack can be an important optimization. I think that both versions are
>> very valid: first mostly for bulk operations = reduction of latency,
>> second for modifications that are acceptable to fail without handling
that.
>> I had the first case in my mind when talking about async operations, and
>> there the futures are necessary.
>>
>> A couple more differences:
>> 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...
>> 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.
>
> 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.
Actually in such a case I would strongly expect Infinispan to keep the
two operations in order. This is not to be pushed on user's
responsibility.
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.
>
> 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.
>
> 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.
+1000
But also I'd stress that any sync operation should have a Future
returned, someone in this long thread suggested to have an option to
drop it for example to speedup bulk imports, but I really can't see a
scenario in which I wouldn't want to know about a failure. Let's not
do the same mistake that made MongoDB so "popular" ;-)
Bulk imports can still be mad efficient without strictly needing to go
these lenghts.
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.
Bulk imports could certainly use putAsync(k, v), and that would indeed
return a Future.
Sanne
>
>>
>>
>> >
>> > Also it depends what you are trying to do with async. Currently async
>> > transport is only for sending messages to another node, we never think
>> > of when we are the owning node. In this case the calling thread would
>> > have to go down the interceptor stack and acquire any locks if it is
>> > the owner, thus causing this "async" to block if you have any
>> > contention on the given key. The use of another thread would allow
>> > the calling thread to be able to return immediately no matter what
>> > else is occurring. Also I don't see what is so wrong about having a
>> > context switch to run something asynchronously, we shouldn't have a
>> > context switch to block the user thread imo, which is very possible
>> > with locking.
>>
>> This is an important notice! Locking would complicate the design a lot,
>> because the thread in "async" mode should do only tryLocks - if this
>> fails, further processing should be dispatched to another thread. Not
>> sure if this could be implemented at all, because the thread may be
>> blocked inside JGroups as well (async API is about receiving the
>> response asynchronously, not about sending the message asynchronously).
>>
>> I don't say that the context switch is that bad. My concern is that you
>> have a very limited amount of requests that can be processed in
>> parallel. I consider a "request" something pretty lightweight in
concept
>> - but one thread per request makes this rather heavyweight stuff.
>>
>> 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.
>>
>>
>> >
>> >> +1 much cleaner, I love it. Actually wasn't aware the current code
>> >> didn't do this :-(
>> > This is what the current async transport does, but it does nothing
with Futures.
>>
>> Nevermind the futures, this is not the important part. It's not about
>> async transport neither, it's about async executors.
>> (okay, the thread was about dropping async transport, I have hijacked
it)
>>
>> Radim
>>
>> --
>> Radim Vansa <rvansa(a)redhat.com>
>> JBoss DataGrid QA
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder(a)redhat.com
>
twitter.com/galderz
>
> Project Lead, Escalante
>
http://escalante.io
>
> Engineer, Infinispan
>
http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev