[infinispan-dev] Ditching ASYNC modes for REPL/DIST/INV/CacheStores?

[Dan Berindei]

On Wed, Feb 19, 2014 at 1:03 PM, Sanne Grinovero <sanne at infinispan.org>wrote:

> On 19 February 2014 07:12, Galder Zamarreño <galder at redhat.com> wrote:
> >
> > On 03 Feb 2014, at 19:01, Dan Berindei <dan.berindei at gmail.com> wrote:
> >
> >>
> >>
> >>
> >> On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <rvansa at 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 at redhat.com>
> >> JBoss DataGrid QA
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > --
> > Galder Zamarreño
> > galder at redhat.com
> > twitter.com/galderz
> >
> > Project Lead, Escalante
> > http://escalante.io
> >
> > Engineer, Infinispan
> > http://infinispan.org
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140219/297a4821/attachment.html