Well, a loggingDelegatorCacheStore is maybe a better idea for this purpose.
Sound like a 3 minutes job... But it's not gonna help me.
Right now, I am not in the CacheStore, I am deep into JClouds ListeningChainingIAmPlayingInThisThreadLookNoNotThisOneTheOtherOneOOpsSorryItIsDeadNow ;-)

phil  

On Sat, Jan 30, 2010 at 11:58 AM, Amin Abbaspour <a.abbaspour@gmail.com> wrote:
Phil,

Why don't you just create a dummy cache-store which does nothing but
log? I think we need this fake story for unit-tests too.

Amin

On Sat, Jan 30, 2010 at 1:53 PM, Philippe Van Dyck <pvdyck@gmail.com> wrote:
> Indeed Manik, I am using the CloudCacheStore... am I lost on a dead branch
> of code ?
> Can I help ? Is the JClouds 1.0-beta3 development on a different branch than
> the snapshot ?
>
> Cheers,
> phil
> On Sat, Jan 30, 2010 at 11:11 AM, Manik Surtani <manik@jboss.org> wrote:
>>
>> Phil,
>> I presume you're using the new CloudCacheStore?  I hope to see a JClouds
>> 1.0-beta3 out this weekend which will be the version used for
>> CloudCacheStore (instead of a JClouds snapshot, which may be the root cause
>> of your 403's).
>> Cheers
>> Manik
>> On 30 Jan 2010, at 09:58, Philippe Van Dyck wrote:
>>
>> Amin,
>> I did some tests too. Unfortunately, they were inconclusive...
>> Using JClouds BlobStore CacheStore I end up with a lot of 'other' problems
>> (right now, I am getting 403 from S3).
>> Since IMO, it is unrelated to the async behavior, I cannot help until I
>> solve the previous bugs.
>> Futures are everywhere in the code now (at least in the BlobStore) and it
>> makes debugging a lot harder since I cannot step easily into code.
>> As soon as I solve the BlobStore issues, I'll get back to this one and
>> post my results...
>> phil
>>
>> On Sat, Jan 30, 2010 at 9:24 AM, Amin Abbaspour <a.abbaspour@gmail.com>
>> wrote:
>>>
>>> I did some tests. Unfortunately my results are not much satisfactory.
>>>
>>> I do confirm that now changes are synced in a separate
>>> CoalescedAsyncStore thread, but the aggregate process we discussed
>>> before here ( https://jira.jboss.org/jira/browse/ISPN-116 )  does not
>>> work anymore. I can see that not the only final value but all
>>> modifications are flushed. (i.e. sync at then end of a 100
>>> modifications period results in 100 stores)
>>>
>>> The other issue is that only cache.put() worked for me this way, and
>>> it ignored all modification via replace for example.
>>>
>>> Let me know if you have done similar tests and your results plz.
>>>
>>> Thanks
>>> Amin
>>>
>>>
>>> On Fri, Jan 29, 2010 at 7:56 PM, Amin Abbaspour <a.abbaspour@gmail.com>
>>> wrote:
>>> > Thanks Galder for such a quickly fix.
>>> >
>>> > like Philippe I was not expecting this major issue to be fixed so
>>> > fast. I have not tested it myself yet, but will check and inform my
>>> > test result tomorrow.
>>> >
>>> > Amin
>>> >
>>> > On Fri, Jan 29, 2010 at 4:15 PM, Manik Surtani <manik@jboss.org> wrote:
>>> >>
>>> >> On 29 Jan 2010, at 12:21, Philippe Van Dyck wrote:
>>> >>
>>> >> Thanks Galder, I could have.
>>> >> As you noticed in the thread, this bug is a blocker for me and since
>>> >> qi4j
>>> >> 1.0 was released two days ago, I am now only waiting for the latest
>>> >> release
>>> >> of JClouds (beta3) to integrate all of them.
>>> >> So having it solved so quickly (!!! :-) ) did change a lot of my
>>> >> schedule
>>> >> these last days and when I asked the previous question I was far away
>>> >> from
>>> >> any fully fledged browser...
>>> >> Until Jira fully integrates with mailing lists, there will be a lag
>>> >> between
>>> >> a "this is done now" message and the "here is the svn log" explanation
>>> >> for
>>> >> anybody with a crappy phone like me ;-)
>>> >> Actually, having Jira manage (or observe) the mailing list could be a
>>> >> very
>>> >> good idea... linking code changes to specific parts of discussions and
>>> >> having Jira to automagically tag it as 'bug' 'task' or 'improvement'
>>> >> would
>>> >> be very nice (Jira could also add links to code...)!
>>> >>
>>> >> Only once JIRA actually fixes and commits bugs (and makes me coffee)
>>> >> will I
>>> >> be truly impressed!  :)
>>> >>
>>> >> phil
>>> >>
>>> >> On Fri, Jan 29, 2010 at 12:19 PM, Galder Zamarreno <galder@jboss.org>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>> On 01/28/2010 06:15 PM, Philippe Van Dyck wrote:
>>> >>> > Could you please be a bit more specific ?
>>> >>> > Are there any test to confirm the closing of the bug ?
>>> >>> > Is it in trunk ?
>>> >>>
>>> >>> Dude, you could at least check the jira and its svn tab!
>>> >>>
>>> >>>
>>> >>>
>>> >>> https://jira.jboss.org/jira/browse/ISPN-340?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
>>> >>>
>>> >>> >
>>> >>> > That sounds like a really good news ;-)
>>> >>> >
>>> >>> > phil
>>> >>> >
>>> >>> > On Thu, Jan 28, 2010 at 6:10 PM, Galder Zamarreno<galder@jboss.org>
>>> >>> >  wrote:
>>> >>> >
>>> >>> >> This is done now.
>>> >>> >>
>>> >>> >> On 01/26/2010 01:10 PM, Amin Abbaspour wrote:
>>> >>> >>> Created https://jira.jboss.org/jira/browse/ISPN-340
>>> >>> >>> You can vote.
>>> >>> >>>
>>> >>> >>> On Tue, Jan 26, 2010 at 3:21 PM, Sanne Grinovero
>>> >>> >>> <sanne.grinovero@gmail.com>   wrote:
>>> >>> >>>> +1
>>> >>> >>>> I don't know if it's correct to consider it a bug, but choices
>>> >>> >>>> on
>>> >>> >>>> JIRA
>>> >>> >>>> are limited.
>>> >>> >>>> I would really need this - performance impact is high - and hope
>>> >>> >>>> they
>>> >>> >>>> could fix it before 4.0
>>> >>> >>>>
>>> >>> >>>> Regards,
>>> >>> >>>> Sanne
>>> >>> >>>>
>>> >>> >>>> 2010/1/26 Amin Abbaspour<a.abbaspour@gmail.com>:
>>> >>> >>>>> Yes Philippe, I think it is a bug.
>>> >>> >>>>>
>>> >>> >>>>> This totally ruins all attempts to create a write-behind async
>>> >>> >>>>> store.
>>> >>> >>>>> I don't know if JBoss Cache had the same issue or not, but for
>>> >>> >>>>> many
>>> >>> >>>>> use-cases (including ours) one will need both TX and
>>> >>> >>>>> write-behind
>>> >>> >>>>> simultaneously.
>>> >>> >>>>>
>>> >>> >>>>> OK, I will open a bug in Jira for 4.0.0-GA.
>>> >>> >>>>>
>>> >>> >>>>> Amin
>>> >>> >>>>>
>>> >>> >>>>> On Tue, Jan 26, 2010 at 2:12 PM, Philippe Van
>>> >>> >>>>> Dyck<pvdyck@gmail.com>
>>> >>> >>   wrote:
>>> >>> >>>>>> Sounds like a good idea.
>>> >>> >>>>>> How do you qualify it ? Bug ? (perf)  Improvement ?
>>> >>> >>>>>> It has a major impact on performance when using the S3
>>> >>> >>>>>> CacheStore,
>>> >>> >>>>>> so
>>> >>> >> I
>>> >>> >>>>>> would like it to be a "performance bug".
>>> >>> >>>>>> WDYT ... especially regarding the planning of the next release
>>> >>> >>>>>> ?
>>> >>> >>>>>> Phil
>>> >>> >>>>>> On Tue, Jan 26, 2010 at 11:28 AM, Amin Abbaspour<
>>> >>> >> a.abbaspour@gmail.com>
>>> >>> >>>>>> wrote:
>>> >>> >>>>>>>
>>> >>> >>>>>>> Hi,
>>> >>> >>>>>>>
>>> >>> >>>>>>> Should I open a jira task for this?
>>> >>> >>>>>>>
>>> >>> >>>>>>> Amin
>>> >>> >>>>>>>
>>> >>> >>>>>>> On Sat, Jan 23, 2010 at 4:59 PM, Amin Abbaspour<
>>> >>> >> a.abbaspour@gmail.com>
>>> >>> >>>>>>> wrote:
>>> >>> >>>>>>>> I guess this is a somehow a bug or typo.
>>> >>> >>>>>>>>
>>> >>> >>>>>>>> Transactions and stores are two separate concepts. While it
>>> >>> >>>>>>>> sounds
>>> >>> >> to
>>> >>> >>>>>>>> flush to normal store at the TX commit but when one
>>> >>> >>>>>>>> knowingly
>>> >>> >>>>>>>> sets
>>> >>> >>>>>>>> store as async, he accepts the risk of consistence in favor
>>> >>> >>>>>>>> of
>>> >>> >> speed.
>>> >>> >>>>>>>>
>>> >>> >>>>>>>> I expect this to be fixed (or at least discussed) before GA.
>>> >>> >>>>>>>>
>>> >>> >>>>>>>> Amin
>>> >>> >>>>>>>>
>>> >>> >>>>>>>> On Sat, Jan 23, 2010 at 3:48 PM, Philippe Van
>>> >>> >>>>>>>> Dyck<pvdyck@gmail.com
>>> >>> >>>
>>> >>> >>>>>>>> wrote:
>>> >>> >>>>>>>>> I do confirm this behavior.
>>> >>> >>>>>>>>> Transactions and asynchronous updates may seem
>>> >>> >>>>>>>>> antagonistic, but
>>> >>> >> they
>>> >>> >>>>>>>>> are
>>> >>> >>>>>>>>> not on a multi-level cache.
>>> >>> >>>>>>>>> I plan to use a synchronous transactional disk cache and a
>>> >>> >>>>>>>>> second
>>> >>> >> non
>>> >>> >>>>>>>>> transactional asynchronous s3 cache, to get the best of
>>> >>> >>>>>>>>> both
>>> >>> >> worlds.
>>> >>> >>>>>>>>> Since the asynchronous aspect of the s3 cache will not
>>> >>> >>>>>>>>> allow me
>>> >>> >>>>>>>>> to
>>> >>> >> get
>>> >>> >>>>>>>>> any
>>> >>> >>>>>>>>> feedback (aka Future), I want it to 'write-behind' in the
>>> >>> >> background
>>> >>> >>>>>>>>> (and
>>> >>> >>>>>>>>> hope everything goes well).
>>> >>> >>>>>>>>> I will wait for the qi4j v1 release (probably Monday),
>>> >>> >>>>>>>>> adapt
>>> >>> >> infinispan
>>> >>> >>>>>>>>> to
>>> >>> >>>>>>>>> the blobstore of jClouds and take a closer look at this in
>>> >>> >>>>>>>>> a
>>> >>> >>>>>>>>> couple
>>> >>> >> of
>>> >>> >>>>>>>>> weeks.
>>> >>> >>>>>>>>> Phil
>>> >>> >>>>>>>>>
>>> >>> >>>>>>>>> On Sat, Jan 23, 2010 at 12:58 PM, Amin Abbaspour
>>> >>> >>>>>>>>> <a.abbaspour@gmail.com>
>>> >>> >>>>>>>>> wrote:
>>> >>> >>>>>>>>>>
>>> >>> >>>>>>>>>> Hi All,
>>> >>> >>>>>>>>>>
>>> >>> >>>>>>>>>> Regarding
>>> >>> >>>>>>>>>>
>>> >>> >>
>>> >>> >> http://community.jboss.org/wiki/Write-ThroughAndWrite-BehindCaching
>>> >>> >>>>>>>>>> , Even if Syncer is in Async mode, but if we modify a key
>>> >>> >>>>>>>>>> inside a
>>> >>> >>>>>>>>>> transaction boundary it is always stored synchronously!
>>> >>> >>>>>>>>>> Why is
>>> >>> >>>>>>>>>> it
>>> >>> >> so?
>>> >>> >>>>>>>>>> How can I have both locking and async store. FYI I use
>>> >>> >>>>>>>>>> JBossTM
>>> >>> >>>>>>>>>> Standalone.
>>> >>> >>>>>>>>>>
>>> >>> >>>>>>>>>> Regards,
>>> >>> >>>>>>>>>> Amin Abbaspour
>>> >>> >>>>>>>>>> _______________________________________________
>>> >>> >>>>>>>>>> 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
>>> >>> >>>>>>
>>> >>> >>>>>>
>>> >>> >>>>>> _______________________________________________
>>> >>> >>>>>> 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
>>> >>> >>>
>>> >>> >>> _______________________________________________
>>> >>> >>> infinispan-dev mailing list
>>> >>> >>> infinispan-dev@lists.jboss.org
>>> >>> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>> >>
>>> >>> >> --
>>> >>> >> Galder Zamarreńo
>>> >>> >> Sr. Software Engineer
>>> >>> >> Infinispan, JBoss Cache
>>> >>> >> _______________________________________________
>>> >>> >> 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
>>> >>> Sr. Software Engineer
>>> >>> Infinispan, JBoss Cache
>>> >>> _______________________________________________
>>> >>> 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
>>> >>
>>> >> --
>>> >> Manik Surtani
>>> >> manik@jboss.org
>>> >> Lead, Infinispan
>>> >> Lead, JBoss Cache
>>> >> http://www.infinispan.org
>>> >> http://www.jbosscache.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
>>
>> --
>> Manik Surtani
>> manik@jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.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