On Wed, Feb 19, 2014 at 1:03 PM, Sanne Grinovero <sa...@infinispan.org>wrote:
> On 19 February 2014 07:12, Galder Zamarreño <gal...@redhat.com> wrote: > > > > On 03 Feb 2014, at 19:01, Dan Berindei <dan.berin...@gmail.com> wrote: > > > >> > >> > >> > >> On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <rva...@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 <rva...@redhat.com> > >> JBoss DataGrid QA > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > -- > > Galder Zamarreño > > gal...@redhat.com > > twitter.com/galderz > > > > Project Lead, Escalante > > http://escalante.io > > > > Engineer, Infinispan > > http://infinispan.org > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
