On 3 Dec 2009, at 19:06, philippe van dyck wrote:
I provided a workaround patch to adrian, it will allow a much better throughput for 4.0,
if you apply it... (Adrian was thinking about an option to specify, maybe in the unsafe
settings?)
I'll have a look at the patch.
> Yes, in which case you won't use the cache store async flag.
But this should be something that only makes sense once the "CloudCacheStore" is
written to use JClouds' BlobStore.
The current JClouds interface (not the next one, the blobstore) currently offers a
Future<> interface.
IMHO, the cache store async flag may be a bad naming when you provide an async
interface.
What you will actually be doing is to pause the stream of updates until the async worker
thread decides to open the door to the real CacheStore.
So, what about calling it the "batch" (or latch?) option instead of the
"async" one ?
Well, it still is asynchronous (i.e., non-blocking) but just not concurrent. (Concurrent
!= asynchronous). Also, batch implies that while *most* calls don't block, *some*
calls will block when the batch needs to be flushed. That is not the case with the async
option, since none of the client threads block.
>>>> If you want to implement an asynchronous interface,
you have to implement it through all the layers or it will be "resynchronized".
>>>>
>>>> The cache store interface does not offer an asynchronous (Future<>)
interface...
>>>>
>>>> IMHO, if you want to allow asynchronous access, you have to begin down
there, and push it up to the AdvancedCache interface.
>>>
>>> We have this already - see Cache.putAsync() for example - but this only
offloads network calls to an executor queue when you have already configured the cache to
use synchronous clustering. As for cache store events, this still happens in the manner
configured (sync or async/batched), although there could be scope for using this API to
offload cache store operations as well.
>>
>> ... What is the need for an async 'batching' executor delegate store,
when you already have an async interface ?
>>
>> Do you think it will be possible to connect the Futures ? The ones produced on
the s3 cache store level (Jclouds), to the ones received from Cache.putAsync ?
>
> Yes.
>
>
http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
How can I access that in the CacheStore interface ? Could you please take a look, with
adrian, to the patch I provided ? It could really use this !
Yeah this is what we need to look into. Like you said, any potential component that *may*
work asynchronously and return a Future should have exposure to this AggregateFuture, so
that the Cache.putAsync(), etc APIs can make use of them. Want to create a JIRA, for
4.1.0? :)
>> If I understand the current situation, asynchronicity is
everywhere ... but unconnected ? Heeeeelp, I need help ;-)
>
> Hehh! :) Yeah, I suppose I now see the need for an AsyncCacheStore interface - but
let's put this on the shelf for a moment, as we need to think about how this affects
other cache store impls that are not implicitly asynchronous.
No problem here, let's postpone to 4.0+! Amazing job done already...
>
> Let's start first with the CloudCacheStore [1]. If you know JClouds well, do you
feel like implementing this with the latest blob store APIs?
I would like to, but I really have no resources for that right now, sorry. And I have a
qi4j EntityStore to finish first ;-)
Thanks again for the help, I will do some EC2 load test this week and if I can
incriminate Infinispan, you (all) be first to know ;-)
Enjoy! :)
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org