On 19 Feb 2014, at 12:03, 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
On 19 Feb 2014, at 17:44, Dennis Reed der...@redhat.com wrote:
On 02/19/2014 12:57 AM, Galder Zamarreño wrote:
On 31 Jan 2014, at 08:32, Dennis Reed der...@redhat.com wrote:
It would be a loss of functionality.
As a common example, the AS web session replication cache is configured
for
On Wed, Feb 26, 2014 at 8:56 AM, Galder Zamarreño gal...@redhat.com wrote:
On 19 Feb 2014, at 12:03, 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 31 Jan 2014, at 08:32, Dennis Reed der...@redhat.com 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
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
On 31 Jan 2014, at 11:59, Sanne Grinovero sa...@infinispan.org wrote:
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
On Wed, Feb 19, 2014 at 1:03 PM, Sanne Grinovero sa...@infinispan.orgwrote:
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:
On 02/19/2014 12:57 AM, Galder Zamarreño wrote:
On 31 Jan 2014, at 08:32, Dennis Reed der...@redhat.com 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
See below...
On Fri, Jan 31, 2014 at 7:35 AM, Radim Vansa rva...@redhat.com 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
On 3 February 2014 14:10, Radim Vansa rva...@redhat.com wrote:
See below...
On Fri, Jan 31, 2014 at 7:35 AM, Radim Vansa rva...@redhat.com wrote:
Worth to note that Infinispan does not have true async operation -
executing synchronous request in another threadpool is rather simplistic
On Mon, Feb 3, 2014 at 9:54 AM, Sanne Grinovero sa...@infinispan.org wrote:
On 3 February 2014 14:10, Radim Vansa rva...@redhat.com wrote:
See below...
On Fri, Jan 31, 2014 at 7:35 AM, Radim Vansa rva...@redhat.com wrote:
Worth to note that Infinispan does not have true async operation -
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
At the JGroups level, ASYNC generates *less* traffic than SYNC. So if
you do sync under the cover and use a future to make it async at the API
level, you're incurring more overhead, namely the messages sending back
the responses.
Not sure about the Infinispan async API, but I'd assume this
On 31/01/14 13:35, Radim Vansa 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
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
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
+1 to moving to the async methods only. I have mentioned this as well
in passing when discussing L1 as there is no way to ensure consistency
with an async transport. Although if we fire the async methods with
either SKIP_REMOTE_LOOKUP/IGNORE_RETURN_VALUES flag than this
consistency is still lost
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
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
19 matches
Mail list logo
