[infinispan-dev] Infinispan S3 Cluster + Store Success ! (+serious performance problems)

[Manik Surtani]

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/infinispan/util/concurrent/AggregatingNotifyingFutureImpl.java?r=328
> 
> 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 at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org