Hi all, The following came to my mind yesterday: I think we should ditch ASYNC modes for DIST/REPL/INV and our async cache store functionality. Instead, whoever wants to store something asyncronously should use asynchronous methods, i.e. call putAsync. So, this would mean that when you call put(), it's always sync. This would reduce the complexity and configuration of our code base, without affecting our functionality, and it would make things more logical IMO. WDYT? Cheers, -- 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

Couldn't this be handled higher up in our implementatoin then ? If I enable an async mode, all puts / gets become putAsync/getAsync transparently to both the application and to the state transfer. Tristan On 01/31/2014 08:32 AM, Dennis Reed wrote: > It would be a loss of functionality. > > As a common example, the AS web session replication cache is configured > for ASYNC by default, for performance reasons. > But it can be changed to SYNC to guarantee that when the request > finishes that the session was replicated. > > That wouldn't be possible if you could no longer switch between > ASYNC/SYNC with just a configuration change. > > -Dennis > > On 01/31/2014 01:08 AM, Galder Zamarreño wrote: >> Hi all, >> >> The following came to my mind yesterday: I think we should ditch ASYNC modes for DIST/REPL/INV and our async cache store functionality. >> >> Instead, whoever wants to store something asyncronously should use asynchronous methods, i.e. call putAsync. So, this would mean that when you call put(), it's always sync. This would reduce the complexity and configuration of our code base, without affecting our functionality, and it would make things more logical IMO. >> >> WDYT? >> >> Cheers, >> -- >> 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 > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Generally I like the systems designed with SYNC_DIST + async shared cachestore. It's probably the best setup we can offer: - you need a shared cachestore for persistence consistency - using SYNC distribution to other replicas provides a fairly decent resilience - if your cachestore needs to be updated in sync, your write performance will be limited by the cachestore performance: this prevents you to use Infinispan to buffer, absorbing write spikes, and reducing write latency

But I agree we should investigate on removing duplicate "asynchronizations" where they are not needed, there might be some opportunities to remove thread switching and blocking. On 31 January 2014 10:48, Tristan Tarrant <ttarrant(a)redhat.com&gt; wrote: > Couldn't this be handled higher up in our implementatoin then ? > > If I enable an async mode, all puts / gets become putAsync/getAsync > transparently to both the application and to the state transfer. > > Tristan > > On 01/31/2014 08:32 AM, Dennis Reed wrote: >> It would be a loss of functionality. >> >> As a common example, the AS web session replication cache is configured >> for ASYNC by default, for performance reasons. >> But it can be changed to SYNC to guarantee that when the request >> finishes that the session was replicated. >> >> That wouldn't be possible if you could no longer switch between >> ASYNC/SYNC with just a configuration change. >> >> -Dennis >> >> On 01/31/2014 01:08 AM, Galder Zamarreño wrote: >>> Hi all, >>> >>> The following came to my mind yesterday: I think we should ditch ASYNC modes for DIST/REPL/INV and our async cache store functionality. >>> >>> Instead, whoever wants to store something asyncronously should use asynchronous methods, i.e. call putAsync. So, this would mean that when you call put(), it's always sync. This would reduce the complexity and configuration of our code base, without affecting our functionality, and it would make things more logical IMO. >>> >>> WDYT? >>> >>> Cheers, >>> -- >>> 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 >> > > _______________________________________________ > 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

Worth to note that Infinispan does not have true async operation - executing synchronous request in another threadpool is rather simplistic solution that has serious drawbacks (I can imagine a situation where I'd do 100 async gets in parallel, but this would drain the whole threadpool).

Implementing that would require serious changes in all interceptors, because you wouldn't be able to call visitWhateverCommand(command) { /* do something */ try { invokeNextInterceptor(command); } finally { /* do another stuff */ } } - you'd have to put all local state prior to invoking next interceptor to context. And you'd need twice as many methods, because now the code would explicitly traverse interceptor stack in both directions.

Still, I believe that this may be something to consider/plan for future. And then, yes, you'd need just put(key, value) { future = putAsync(key, value); return sync ? future.get() : null; }

Radim On 01/31/2014 11:48 AM, Tristan Tarrant wrote: > Couldn't this be handled higher up in our implementatoin then ? > > If I enable an async mode, all puts / gets become putAsync/getAsync > transparently to both the application and to the state transfer. > > Tristan > > On 01/31/2014 08:32 AM, Dennis Reed wrote: >> It would be a loss of functionality. >> >> As a common example, the AS web session replication cache is configured >> for ASYNC by default, for performance reasons. >> But it can be changed to SYNC to guarantee that when the request >> finishes that the session was replicated. >> >> That wouldn't be possible if you could no longer switch between >> ASYNC/SYNC with just a configuration change. >> >> -Dennis >> >> On 01/31/2014 01:08 AM, Galder Zamarreño wrote: >>> Hi all, >>> >>> The following came to my mind yesterday: I think we should ditch ASYNC modes for DIST/REPL/INV and our async cache store functionality. >>> >>> Instead, whoever wants to store something asyncronously should use asynchronous methods, i.e. call putAsync. So, this would mean that when you call put(), it's always sync. This would reduce the complexity and configuration of our code base, without affecting our functionality, and it would make things more logical IMO. >>> >>> WDYT? >>> >>> Cheers, >>> -- >>> 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 >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

See below... On Fri, Jan 31, 2014 at 7:35 AM, Radim Vansa <rvansa(a)redhat.com&gt; wrote: >> Worth to note that Infinispan does not have true async operation - >> executing synchronous request in another threadpool is rather simplistic >> solution that has serious drawbacks (I can imagine a situation where I'd >> do 100 async gets in parallel, but this would drain the whole threadpool). > I agree if we could optimize this with batching it would make it better. > >> Implementing that would require serious changes in all interceptors, >> because you wouldn't be able to call >> >> visitWhateverCommand(command) { >> /* do something */ >> try { >> invokeNextInterceptor(command); >> } finally { >> /* do another stuff */ >> } >> } >> >> - you'd have to put all local state prior to invoking next interceptor >> to context. And you'd need twice as many methods, because now the code >> would explicitly traverse interceptor stack in both directions. > I am not quite sure what you mean here. Async transport currently > traverses the interceptors for originator and receiver (albeit > originator goes back up without a response). > >> Still, I believe that this may be something to consider/plan for future. >> >> And then, yes, you'd need just >> >> put(key, value) { >> future = putAsync(key, value); >> return sync ? future.get() : null; >> } > 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.

Radim _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

>>> 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.

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.

> +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.

On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <rvansa(a)redhat.com&gt; 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.

> > 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&gt; 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

On 19 February 2014 07:12, Galder Zamarreño <galder(a)redhat.com&gt; wrote: > > On 03 Feb 2014, at 19:01, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > >> >> >> >> On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <rvansa(a)redhat.com&gt; 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.

> > 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.

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&gt; >> 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

On 19 Feb 2014, at 12:03, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > On 19 February 2014 07:12, Galder Zamarreño <galder(a)redhat.com&gt; wrote: >> >> On 03 Feb 2014, at 19:01, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >> >>> >>> >>> >>> On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa <rvansa(a)redhat.com&gt; 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. If the two operations are executed by the same thread, then yes, I agree that it should be applied one after the other: Thread-1: Future f1 = putAsync(k, v1); Thread-1: Future f2 = putAsync(k, v2); I'd expect v1 to be applied and then v2. This operations would be added to some queue that you'd expect both insertions to happen one after the other, in Thread-1, so yeah, we can apply them in order.

However, if the following happens: Thread-1: Future f1 = putAsync(k, v1); Thread-2: Future f2 = putAsync(k, v2); We can't be enforcing such ordering. Now, if there's a relationship to the eye of the beholder between v1 and v2, and you expect v2 to be the end result, this is how you'd have to do it (JDK8-esque): Thread-1: Future f1 = putAsync(k, v1); Thread-2: Future f2 = f1.map.putAsync(k, v2); or: Thread-1: Future f1 = putAsync(k, v1); Thread-2: Future f2 = f1.map.replaceAsync(k, v1, v2);

> >> >> 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, ^ To me, purely sync operations are any operations that return anything other than a Future. IOW: void put(k, v); ^ That's an implicit sync operation where you have no choice. An async operation can behave both sync and async: Future<Void> put(k, v); Can be sync or async, depends on whether the user waits or does something once it completes. If it does not wait, or discards the Future, it's async. If it does somethign with the future, it's sync.

> 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. +1, I think everything should return a Future.

> 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. > > 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&gt; >>> 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 -- 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

It would be a loss of functionality. As a common example, the AS web session replication cache is configured for ASYNC by default, for performance reasons. But it can be changed to SYNC to guarantee that when the request finishes that the session was replicated. That wouldn't be possible if you could no longer switch between ASYNC/SYNC with just a configuration change.

-Dennis On 01/31/2014 01:08 AM, Galder Zamarreño wrote: > Hi all, > > The following came to my mind yesterday: I think we should ditch ASYNC modes for DIST/REPL/INV and our async cache store functionality. > > Instead, whoever wants to store something asyncronously should use asynchronous methods, i.e. call putAsync. So, this would mean that when you call put(), it's always sync. This would reduce the complexity and configuration of our code base, without affecting our functionality, and it would make things more logical IMO. > > WDYT? > > Cheers, > -- > 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

On 02/19/2014 12:57 AM, Galder Zamarreño wrote: > On 31 Jan 2014, at 08:32, Dennis Reed <dereed(a)redhat.com&gt; wrote: > >> It would be a loss of functionality. >> >> As a common example, the AS web session replication cache is configured >> for ASYNC by default, for performance reasons. >> But it can be changed to SYNC to guarantee that when the request >> finishes that the session was replicated. >> >> That wouldn't be possible if you could no longer switch between >> ASYNC/SYNC with just a configuration change. > I disagree :). > > AS could abstract that configuration detail. IOW, if all Infinispan returned was Futures, AS or any other client application, has the choice in their hands: do they wait for the future to complete or not? If they do, they’re SYNC, if not ASYNC. AS can still expose this and no functionality is lost. Yes, the functionality is still lost. Your suggestion is just to re-implement the functionality over and over in each ISPN caller. :)

> What happens is that SYNC/ASYNC decision stops being a configuration option (bad, bad, bad) and becomes an actual programming decision Infinispan clients must address (good, good, good). This really depends on the client. For the AS session replication use case, a config option is good, good, good. But re-implementing the same functionality in every caller that may want it to be a config option is bad, bad, bad. -Dennis >> -Dennis >> >> On 01/31/2014 01:08 AM, Galder Zamarreño wrote: >>> Hi all, >>> >>> The following came to my mind yesterday: I think we should ditch ASYNC modes for DIST/REPL/INV and our async cache store functionality. >>> >>> Instead, whoever wants to store something asyncronously should use asynchronous methods, i.e. call putAsync. So, this would mean that when you call put(), it's always sync. This would reduce the complexity and configuration of our code base, without affecting our functionality, and it would make things more logical IMO. >>> >>> WDYT? >>> >>> _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev