great... I'll restart my test this evening (it's 10:00am here)... Tomorrow is a bank day I'll restart Friday and keep you informed!
First results of load test I ran last week are better with ehCache in term of memory usage and recycling. Seems to be encouraging... Thanks Aurélien 2009/11/10 Mark Mandel <[email protected]> > Okay guys, feel free to test away!!! > > Only caveat - I've yet to come up with a common API for statistics (So the > Monitor doesn't work), and also how to expose the cache providers to the > outside world, so you can interact with them natively if need be, but that > shouldn't stop you getting stuck in. > > Mark > > > On Mon, Nov 9, 2009 at 6:48 AM, Mark Mandel <[email protected]> wrote: > >> Just to keep updating - >> >> I'm still working on this. EventManager Unit Tests are passing, but a few >> are failing in Composite Keys. >> >> cf.Objective(ANZ) is taking up a lot of time this week, but I hope I have >> some time to keep working. >> >> Mark >> >> >> On Thu, Nov 5, 2009 at 10:50 PM, Mark Mandel <[email protected]>wrote: >> >>> The EventManager Unit Tests are the ones that are currently failing at >>> the moment ;o) >>> >>> >>> Mark >>> >>> 2009/11/5 Aurélien DELEUSIÈRE <[email protected]> >>> >>>> Yes, this is the branch I've checked out and I found this xml too. >>>> >>>> I'm conscient that is not final, I'm using this on my own dev env. I'm >>>> just curious to see how is the pain... ;-) >>>> >>>> I've started to play with, no "big" problem for the moment. The >>>> application starts. >>>> >>>> The events binding seems not working. Will it work or I've to >>>> investigated on ehCache side ? >>>> ApplicationObserver.cfc->init(application.oTransfer) : >>>> // auto register this observer >>>> oTransfer.addBeforeCreateObserver(this); >>>> oTransfer.addAfterCreateObserver(this); >>>> >>>> oTransfer.addBeforeUpdateObserver(this); >>>> oTransfer.addAfterUpdateObserver(this); >>>> >>>> oTransfer.addBeforeDeleteObserver(this); >>>> oTransfer.addAfterDeleteObserver(this); >>>> >>>> Thanks! >>>> >>>> >>>> 2009/11/5 Mark Mandel <[email protected]> >>>> >>>>> Aurelien, >>>>> >>>>> The code in progress is not stored in the trunk, it is stored in a >>>>> branch. >>>>> >>>>> http://svn.riaforge.org/transfer/transfer/branches/pluggable_cache/ >>>>> >>>>> I'm not 100% sure this is ready for general usage yet, as there are >>>>> several unit test suites that are not yet completing. Use very much at >>>>> your >>>>> own risk. >>>>> >>>>> The default ehcache config is found here: >>>>> >>>>> http://svn.riaforge.org/transfer/transfer/branches/pluggable_cache/com/cache/provider/ehcache-lib/ehcache.xml >>>>> >>>>> Although there are plenty of examples in the EHCache documentation. >>>>> >>>>> Mark >>>>> >>>>> 2009/11/5 Aurélien DELEUSIÈRE <[email protected]> >>>>> >>>>>> Hello Mark - >>>>>> >>>>>> Thanks for the work. I've checked out the trunk. I'm going to switch >>>>>> this today. I'm discovering the ehcache.xml config (first time). If you >>>>>> have >>>>>> a simple ready to use xml file I'm intereted in. >>>>>> >>>>>> Thanks - >>>>>> Aurelien >>>>>> >>>>>> 2009/11/4 Mark Mandel <[email protected]> >>>>>> >>>>>> Just letting you all know this is alive and kicking. >>>>>>> >>>>>>> I'm just polishing off the final tests, and resolving any issues that >>>>>>> I have found. >>>>>>> >>>>>>> While this is a break in backwards compatibility, this has simplified >>>>>>> much of Transfer architecture, and streamlined it very nicely. >>>>>>> >>>>>>> Should see some code that is ready for testing in a day or two. >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 2, 2009 at 11:53 PM, Mark Mandel >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> I'm about to go to bed, but I'll give you all an update. >>>>>>>> >>>>>>>> The <objectCache> section now looks akin to this: >>>>>>>> >>>>>>>> <objectCache> >>>>>>>> <defaultcache >>>>>>>> provider="transfer.com.cache.provider.EHCacheProvider"> >>>>>>>> <setting name="config" value="/test/resources/ehcache.xml"/> >>>>>>>> </defaultcache> >>>>>>>> <cache class="none.Basic" >>>>>>>> provider="transfer.com.cache.provider.NoCacheProvider"/> >>>>>>>> <cache class="none.Child" >>>>>>>> provider="transfer.com.cache.provider.NoCacheProvider"/> >>>>>>>> </objectCache> >>>>>>>> >>>>>>>> So the 'provider' attribute specifies what Cache Provider, which is >>>>>>>> a CFC that extends AbstractBaseProvider, which can be found here: >>>>>>>> >>>>>>>> http://svn.riaforge.org/transfer/transfer/branches/pluggable_cache/com/cache/provider/AbstractBaseProvider.cfc >>>>>>>> >>>>>>>> The <setting> values get pass to the init() of the Provider. >>>>>>>> >>>>>>>> (Some more basic statistic based methods will be added later for >>>>>>>> simple reporting, and tied back into the CacheMonitor) >>>>>>>> >>>>>>>> So you see you can set up a defaultCacheProvider, and also use a >>>>>>>> specific CacheProvider for specific classes as well - so you can mix >>>>>>>> and >>>>>>>> match caches (possibly at your own peril ;o) ) >>>>>>>> >>>>>>>> Because you can also extend the Provider yourself, you can do all >>>>>>>> sorts of weird and wonderful things. >>>>>>>> >>>>>>>> I'm writing up an EHCache one as the default, which will have some >>>>>>>> limitations as to the platform it can do things on (No CF7, quite >>>>>>>> possibly >>>>>>>> not going to work on some shared hosts, due to classpath >>>>>>>> restrictions), so >>>>>>>> I'll be looking for other people to do some intergration as well (A >>>>>>>> ColdBox >>>>>>>> cache adapter would be really cool, or any other cache framework). >>>>>>>> The only >>>>>>>> major dependency is that the cache framework has to be able to tell >>>>>>>> you when >>>>>>>> something gets discarded, as that is how Objects know to drop >>>>>>>> collections >>>>>>>> and the like when things get deleted/discarded from the cache. >>>>>>>> >>>>>>>> Anyway, it's almost midnight here, I'm gonna grab some shut eye... >>>>>>>> and then get up tomorrow morning and rip apart Transfer some more as >>>>>>>> the >>>>>>>> whole nation stops for a horse race... >>>>>>>> >>>>>>>> Mark >>>>>>>> >>>>>>>> -- >>>>>>>> E: [email protected] >>>>>>>> T: http://www.twitter.com/neurotic >>>>>>>> W: www.compoundtheory.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> E: [email protected] >>>>>>> T: http://www.twitter.com/neurotic >>>>>>> W: www.compoundtheory.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Aurélien Deleusière >>>>>> Mobile : +33 (0)6 83 78 83 42 >>>>>> >>>>>> ad e-consulting >>>>>> expertise 2.0 >>>>>> >>>>>> 104, Grande Rue - 92310 Sèvres >>>>>> S.A.R.L. au capital de 8500€ >>>>>> R.C.S. Nanterre 50177609000018 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> E: [email protected] >>>>> T: http://www.twitter.com/neurotic >>>>> W: www.compoundtheory.com >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> -- >>> E: [email protected] >>> T: http://www.twitter.com/neurotic >>> W: www.compoundtheory.com >>> >>> >> >> >> -- >> E: [email protected] >> T: http://www.twitter.com/neurotic >> W: www.compoundtheory.com >> >> > > > -- > E: [email protected] > T: http://www.twitter.com/neurotic > W: www.compoundtheory.com > > > > > -- Aurélien Deleusière Mobile : +33 (0)6 83 78 83 42 ad e-consulting expertise 2.0 104, Grande Rue - 92310 Sèvres S.A.R.L. au capital de 8500€ R.C.S. Nanterre 50177609000018 --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
