RE: [jbosscache-dev] Need for CacheLoader.storeState?
by Vladimir Blagojevic
Good stuff.
No ideas yet about improving transfer format (at least from me). Thought
of hand serializing fqns as strings but now fqns can have any object as
path elements so that's out. During state transfer operation inevitable
put and get from underlying cacheloader are much more expensive and I am
not sure if it will make much difference in the end?
> -----Original Message-----
> From: Bela Ban
> Sent: Thursday, August 31, 2006 5:47 PM
> To: Vladimir Blagojevic
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Need for CacheLoader.storeState?
>
> Absolutely, I had that idea when I wrote the cache loader
> interface, but never saw it through... +1 for sure, this
> takes a lot of pain out of the implementations.
>
> Are you guys thinking about a more efficient transfer format,
> or is NodeData still the awy to go ?
>
> Vladimir Blagojevic wrote:
> > Hi,
> >
> > After we resolve streaming format incompatible cacheloader
> > implementations [1][2], and as we continue to follow newly agreed
> > streaming state transfer format - we do not have to require
> > cacheloader implementers to write their own implementations of
> > storeEntireState and storeState !
> >
> > CacheLoader.storeEntireState and CacheLoader.storeState are
> always the
> > same. They read NodeData objects from stream and call put with
> > underlying cacheloader. Put method does the cacheloader
> specific stuff.
> >
> > We can possibly keep storeEntireState and storeState in CacheLoader
> > API but move default implementations to AbstractCacheLoader. Any
> > suggestions or opinions?
> >
> >
> > [1] http://jira.jboss.com/jira/browse/JBCACHE-748
> > [2] http://jira.jboss.com/jira/browse/JBCACHE-749
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >
> >
>
> --
> Bela Ban
> Lead JGroups / Manager JBoss Clustering Group JBoss - a
> division of Red Hat
>
>
19 years
Need for CacheLoader.storeState?
by Vladimir Blagojevic
Hi,
After we resolve streaming format incompatible cacheloader
implementations [1][2], and as we continue to follow newly agreed
streaming state transfer format - we do not have to require cacheloader
implementers to write their own implementations of storeEntireState and
storeState !
CacheLoader.storeEntireState and CacheLoader.storeState are always the
same. They read NodeData objects from stream and call put with
underlying cacheloader. Put method does the cacheloader specific stuff.
We can possibly keep storeEntireState and storeState in CacheLoader API
but move default implementations to AbstractCacheLoader. Any suggestions
or opinions?
[1] http://jira.jboss.com/jira/browse/JBCACHE-748
[2] http://jira.jboss.com/jira/browse/JBCACHE-749
19 years
AsyncCacheLoader state transfer problems
by Vladimir Blagojevic
Hi,
Working closely with cachloaders in the last two weeks I've noticed that
current implementation of AsyncCacheLoader, if I understand things
correctly, might lead to potenntial problems.
If you recall, jbc state transfer (both streaming and byte based)
algorithm is basically:
-acquire lock on root
-transfer state (receive or send)
-release lock on root
Transfer state part of this algorithm is done through cacheloader API
calls (loadState/storeState etc). Besides lock
acquisition/transfer/release there is also a lot of stream creation,
cleanup, etc etc. This algorithm is good as long as we are running on
one thread.
AsyncCacheLoader does not conform to these assumptions since it runs all
operations on its own thread. It seems like that we have to exempt
load/store state operations from being done on separate, asynch
cacheloader thread.
Any thoughts?
19 years
Re: Cacheloader change done
by Manik Surtani
Great, thanks!
We're getting close to finishing up with the 2.0.0 API changes too -
I'm thinking of cutting a developer release pretty soon. I'd like
your streaming state transfer stuff to be in as well. When do you
think we can have this in?
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 31 Aug 2006, at 16:38, Vladimir Blagojevic wrote:
> Manik,
>
> I've finished this change. There will still be some problems here and
> there but I'll continue to work on this until it is polished up.
>
> Vladimir
19 years
printDetails()
by Ben Wang
Manik,
Do we intend to preserve the printDetails() api to print out the cache content? It is kind of handy for debugging. What's the alternative?
Thanks,
-Ben
19 years
_get()
by Ben Wang
Manik,
Another quick question in Cache 2.0. In 2.0, I need to do something like skipping all the lock and interceptors with _get(). Is there a equivalent way of doing it?
Cheers,
-Ben
19 years
Usage of Option override
by Ben Wang
Manik,
Maybe I have missed something here. But what's the best usage of overriding the Option in 2.0? Currently, I have to do like:
gravitateOption_.setForceDataGravitation(true);
cache_.getInvocationContext().setOptionOverrides(gravitateOption_);
Object obj = cache_.get(fqn, key);
gravitateOption_.setForceDataGravitation(false);
cache_.getInvocationContext().setOptionOverrides(gravitateOption_);
return obj;
Of which is painful. I can use getOptionOverrides to retrieve the option and set it there. However, should I also check for nullity there?
Thanks,
-Ben
19 years
Usage of Option override
by Ben Wang
Manik,
Maybe I have missed something here. But what's the best usage of overriding the Option in 2.0? Currently, I have to do like:
gravitateOption_.setForceDataGravitation(true);
cache_.getInvocationContext().setOptionOverrides(gravitateOption_);
Object obj = cache_.get(fqn, key);
gravitateOption_.setForceDataGravitation(false);
cache_.getInvocationContext().setOptionOverrides(gravitateOption_);
return obj;
Of which is painful. I can use getOptionOverrides to retrieve the option and set it there. However, should I also check for nullity there?
Thanks,
-Ben
19 years
RE: JBoss Cache cruise control
by Rajesh Rajasekaran
The URL would be the same.
http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite
Both these boxes share a common drive.
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Wednesday, August 30, 2006 10:59 AM
To: Rajesh Rajasekaran
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: JBoss Cache cruise control
Thanks, Rajesh.
Could you pls email the list with the new URL to access test results.
Thanks,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 30 Aug 2006, at 16:24, Rajesh Rajasekaran wrote:
> The main CC build box is cramped with the AS testsuite having multiple
> runs on different jvms's. I ll move the cache testsuite to a different
> box and schedule it at midnight EST.
>
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Wednesday, August 30, 2006 10:15 AM
> To: QA
> Subject: JBoss Cache cruise control
>
> Hi guys
>
> I see cc runs the JBC test suite roughly every one-and-a-half days
> now. Is there any chance we can bring this in to a nightly build?
> And perhaps even schedule it such that it kicks off around midnight
> (EST) so it is done by the time I come online in the morning?
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
19 years
Re: JBoss Cache cruise control
by Manik Surtani
Thanks, Rajesh.
Could you pls email the list with the new URL to access test results.
Thanks,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 30 Aug 2006, at 16:24, Rajesh Rajasekaran wrote:
> The main CC build box is cramped with the AS testsuite having multiple
> runs on different jvms's. I ll move the cache testsuite to a different
> box and schedule it at midnight EST.
>
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Wednesday, August 30, 2006 10:15 AM
> To: QA
> Subject: JBoss Cache cruise control
>
> Hi guys
>
> I see cc runs the JBC test suite roughly every one-and-a-half days
> now. Is there any chance we can bring this in to a nightly build?
> And perhaps even schedule it such that it kicks off around midnight
> (EST) so it is done by the time I come online in the morning?
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
19 years
