Menu
▾
▴
jpolycache-users — JCS mailing list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: vze2dcyq <aar...@ve...> - 2001-07-27 01:18:57
|
-----Original Message----- From: vze2dcyq [mailto:aar...@ve...] Sent: Tuesday, July 24, 2001 8:40 PM To: tur...@ja... Subject: cache (JCS) -- RE: where is org.apache.turbine.util.TurbineConfig The JCS is a third generation system. I have a completely stable version of a very similar cache running in production with most of the same features. The JCS is a major revision but is built on the same foundation. I've been trying to get it closer to JCACHE without introducing too many bugs. I'm ironing out some kinks right now. I have 5 relatively minor things to do before I'll be satisfied: 1. Optimize the element attribute class, with is a simple matter that I've been putting off. 2. Get any bugs out of the group attribute list that I might have introduced recently. 3. Test the disk purgatory a little harder. 4. Finish the last few steps of clustering and remote failover. 5. Clean out a few unused classes relating to remote server clustering. I'll keep you updated on my progress. Aaron -----Original Message----- From: dl...@de... [mailto:dl...@de...]On Behalf Of Daniel Rall Sent: Tuesday, July 24, 2001 3:25 PM To: tur...@ja... Subject: Re: where is org.apache.turbine.util.TurbineConfig Jason van Zyl <jv...@ap...> writes: > On 7/24/01 1:34 PM, "Daniel Rall" <dl...@fi...> wrote: > > > Jason van Zyl <jv...@ap...> writes: > > > >> I think I'm going to try Aaron's jpolycache which looks like it will > >> support this. > > > > Anyone else had any experience with that yet? I never did find time > > to look at it. > > I think the only other option I think is the cache package in the > commons sandbox. But Aaron has been working on jpolycache for two > years and the code looks pretty good to me. He's also sent me > an example of how turbine could easily hook into jpolycache. 2 years is impressive. > I'm hoping that he tries to make a service for Fulcrum as I believe > it would be widely used if made part of an embeddable service > framework. I would start using such a service immediately. Dan --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: vze2dcyq <aar...@ve...> - 2001-07-27 01:18:46
|
-----Original Message----- From: dl...@de... [mailto:dl...@de...]On Behalf Of Daniel Rall Sent: Tuesday, July 24, 2001 3:25 PM To: tur...@ja... Subject: Re: where is org.apache.turbine.util.TurbineConfig Jason van Zyl <jv...@ap...> writes: > On 7/24/01 1:34 PM, "Daniel Rall" <dl...@fi...> wrote: > > > Jason van Zyl <jv...@ap...> writes: > > > >> I think I'm going to try Aaron's jpolycache which looks like it will > >> support this. > > > > Anyone else had any experience with that yet? I never did find time > > to look at it. > > I think the only other option I think is the cache package in the > commons sandbox. But Aaron has been working on jpolycache for two > years and the code looks pretty good to me. He's also sent me > an example of how turbine could easily hook into jpolycache. 2 years is impressive. > I'm hoping that he tries to make a service for Fulcrum as I believe > it would be widely used if made part of an embeddable service > framework. I would start using such a service immediately. Dan --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: vze2dcyq <aar...@ve...> - 2001-07-27 01:18:36
|
-----Original Message----- From: Jason van Zyl [mailto:jv...@ap...] Sent: Tuesday, July 24, 2001 1:43 PM To: tur...@ja... Subject: Re: where is org.apache.turbine.util.TurbineConfig On 7/24/01 1:34 PM, "Daniel Rall" <dl...@fi...> wrote: > Jason van Zyl <jv...@ap...> writes: > >> I think I'm going to try Aaron's jpolycache which looks like it will >> support this. > > Anyone else had any experience with that yet? I never did find time > to look at it. I think the only other option I think is the cache package in the commons sandbox. But Aaron has been working on jpolycache for two years and the code looks pretty good to me. He's also sent me an example of how turbine could easily hook into jpolycache. I'm hoping that he tries to make a service for Fulcrum as I believe it would be widely used if made part of an embeddable service framework. > Dan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tur...@ja... > For additional commands, e-mail: tur...@ja... -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <AS...@th...> - 2001-07-10 16:28:23
|
I'm glad you are interested. There really is no viable distributed caching system provided by any app server, except maybe Oracle9i. I'm running another version of this in production and it is working great, but I've tried to add several features and have pretty much redone the entire thing. I'm almost done with remote cache clustering. Once I finish, this will be a far better system than Oracle's. If you put the main cache folder in c:\dev\ the tester code should be fine. I haven't updated the files in a few weeks. This last week I haven't had much time to work on it, but I should be able to get clustering done shortly. I need to write some documents on how it works. I'll make some examples. I'll definitely need some help. First I need to finish the clustering, just a few little things and then I need to take a few methods out of the access interface and speed up the attribute setting in the element attribute class. Then we need to do more performace tuning. Also, it would be nice to have a versioning feature, where an element's version number could be used to add another layer of protection against out of sych data problems. The disk cache and the remote work nicely. The lateral tcp distribution cache should be ok, but I don't think it is a good model to follow. This is primarily how Oracle's system works. There is a little documentation in the mailing list archive. Mostly messages from the Jakarta commons and Turbine lists. When i get this stable enough it will go into the commons project and should improve dramatically. Aaron -----Original Message----- From: Greg Haverkamp [mailto:gr...@ha...] Sent: Monday, July 09, 2001 7:00 PM To: jpo...@li... Subject: [Jpolycache-users] Status? I was wondering if someone had a capsule on the state of the jpolycache implementation, as well as a list of tasks where help might be needed. I was in the pre-implementation phase of my own jcache mini-implementation when I discovered this work on SourceForge, and I was able to get some things running in a matter of an hour or so last night. However, I generate a fair number of errors, and without having spent a lot of time looking at the code, it wasn't clear to me that what I was seeing was what I wanted. Specifically, while I had objects (Strings) going into and out of the cache, I always lost the first. And it appeared to me that only Disk and Remote caches were implemented at this time. A quick rundown on what I'm doing. I'm working on specifying and implementing the caching infrastructure for the ArsDigita Community System, an open-source framework for developing web applications (http://developer.arsdigita.com/acs-java). Our current plan is to develop as little of a caching infrastructure as needed while leveraging those built by the app server vendors through a facade. So far, Oracle seems to have the only worthwhile vendor-supplied caching solution. Anyhow, I've been told I can take some development cycles to either: a) implement something small and limited on my own or b) contribute to another open-source implementation. Sorry for the rambling tone. Greg _______________________________________________ Jpolycache-users mailing list Jpo...@li... http://lists.sourceforge.net/lists/listinfo/jpolycache-users |
|
From: Greg H. <gr...@ha...> - 2001-07-09 23:04:38
|
I was wondering if someone had a capsule on the state of the jpolycache implementation, as well as a list of tasks where help might be needed. I was in the pre-implementation phase of my own jcache mini-implementation when I discovered this work on SourceForge, and I was able to get some things running in a matter of an hour or so last night. However, I generate a fair number of errors, and without having spent a lot of time looking at the code, it wasn't clear to me that what I was seeing was what I wanted. Specifically, while I had objects (Strings) going into and out of the cache, I always lost the first. And it appeared to me that only Disk and Remote caches were implemented at this time. A quick rundown on what I'm doing. I'm working on specifying and implementing the caching infrastructure for the ArsDigita Community System, an open-source framework for developing web applications (http://developer.arsdigita.com/acs-java). Our current plan is to develop as little of a caching infrastructure as needed while leveraging those built by the app server vendors through a facade. So far, Oracle seems to have the only worthwhile vendor-supplied caching solution. Anyhow, I've been told I can take some development cycles to either: a) implement something small and limited on my own or b) contribute to another open-source implementation. Sorry for the rambling tone. Greg |
|
From: vze2dcyq <aar...@ve...> - 2001-07-03 01:25:32
|
Hi: I created a web publishing framework for Inside.com that was integrated into a caching system that allowed for pages to be sectioned into elements of varying dynamicity. Each element could be rebuilt from the database or pulled from the cache. Some of the pages had around 20 discrete components. Other pod pages were composed of elements that were built by action classes that implemented a common interface, so they could be ordered and chosen. Content passed through a full quark-like work flow system. Then it was ranked and published. Publication would issue cache deletion commands to all the subscribed local caches. This caching system performed far better than Vignette's story server and was the backbone of the publishing system. I'm currently working on a revision that is closer to the jcache jsr proposal by Oracle. You might be interested. You can check the Jakarta Turbine and Commons mailing list archives for more information. http://sourceforge.net/projects/jpolycache/ I've included some screen shots of a couple pages in the publishing system, but the email was too big. Aaron |
|
From: vze2dcyq <aar...@ve...> - 2001-06-29 05:31:42
|
Hi: Thanks for the link to the ocs4j jar. There are some nice optimizations in the ocs4j system. 9i looks like it will be far ahead of its competition. My original system was much like this. I started out with a laterally distributed system that was regionally configured (somewhat programmatically). I moved to a centralized remote system to avoid network chatter, then added groups. Then after looking at the jcache specification I decided to move to a system that could be controlled by each element's attributes. I've decided against full configuration by user classes, since if you can take the time to type configuration information into code, you can add it to a props file and do it right. I broke from the set implementation model and moved to a more configurable system with plugable auxiliary caches that can be created by users. This will be the major "selling point" of my implementation. In a few weeks I should have a stable version where the remote caches are fully clusterable, where there is no point of failure. I also need fully implement the distributes session code from the (regionally controlled) system I have in production. I can take down as many machines and app servers as I want, so long as 1 is running, and I never loose any session data . . . No one offers this, not even Weblogic. This shouldn't take me much longer. At that time I'll be able to offer an ocs4j vs. jcs comparison. After this I will implement versioning as an option, clean up the access interface, optimize the attribute code (by implementing custom serialization), and write more documentation. Thanks again for mentioning my work and sending me the helpful links. Aaron -----Original Message----- From: HSt...@Cl... [mailto:HSt...@Cl...] Sent: Thursday, June 28, 2001 7:54 PM To: Jerry Bortvedt Cc: aar...@ve... Subject: Re: Comment on OCS4J/ JSR-107 Thanks for the reply! Is there any working code available to outside developers already? There is a similar free API (http://sourceforge.net/projects/jpolycache/ ) maintained by Aaron Smuts and is likely to go in the Jakarta/Apache Commons effort. Regards, R&D Soft. Eng, VNU-CLARITAS San Diego, CA Jerry Bortvedt <jerry.bortvedt@o To: HSt...@Cl... racle.com> cc: Subject: Re: Comment on OCS4J/ JSR-107 06/28/2001 04:29 PM Hi Hristo, Thanks for the input. Actually that is the way it is in the JSR spec. The OCS4J implementation on OTN does not implement the JSR. That implementation is the basis for the JSR but the details and some of the functionality will be different. The JSR has not been released for public review yet. Jerry HSt...@Cl... wrote: > Jerry-, > One comment on OCS4J: > The distributed protocol should be made optional and separated from the > core package. > The reason: distributed cache management could be done with other means. > For example, I would use JINI distributed transactions, secured RMIs and > event notification(messaging) > to better handle networked caches. Or someone else can use EJB + JMS for > exactly the same reason. > > Thanks, > Hristo > > > Jerry Bortvedt > <jerry.bortvedt@o To: HSt...@Cl... > racle.com> cc: > Subject: Re: OCS4J availability > 06/28/2001 02:37 > PM > > > > Hi Hristo, > > Try http://otn.oracle.com/products/ocs4j/content.html I don't off hand > know what the licensing agreement is for this, so whether it is free > probably depends on how you want to use it. > > Jerry > > HSt...@Cl... wrote: > > > Hi Jerry! > > I am interested in using OCS4J NOW. Is Oracle offering OCS4J > > as a separate free package (I checked OTN and found nothing). > > Thnaks in advance! > > > > Hristo > > (See attached file: jerry.bortvedt.vcf) (See attached file: jerry.bortvedt.vcf) |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:42
|
-----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: Thursday, June 07, 2001 9:14 AM To: tur...@ja... Subject: the cache zip files are fine http://www.psoft.net/~asmuts/ -----Original Message----- From: Aaron Smuts [mailto:aar...@ve...] Sent: Wednesday, June 06, 2001 11:04 PM To: tur...@ja... Subject: RE: url of cache -- RE: working version of an attribute driven cache There seems to be something wrong with my windows 2000 version of winzip (I can't open it on 98). I'll have a good file tomorrow. Sorry -----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: Wednesday, June 06, 2001 6:35 PM To: tur...@ja... Subject: url of cache -- RE: working version of an attribute driven cache Here you go. Sorry, the scripts are set up so the cache.zip must be unzipped in c:\dev\ and they have a hard coded javahome. I'll make something more user flriendly tomorrow. It will create a cache subfolder. I didn't include Unix test scripts in the bin. The run script starts the command line test program. The startRemoteCache.bat and stopRemoteCache.bat scripts do what they sound like. I had to borrow some web space: http://www.psoft.net/~asmuts/ Aaron -----Original Message----- From: Jason van Zyl [mailto:jv...@ap...] Sent: Wednesday, June 06, 2001 12:46 PM To: tur...@ja... Subject: Re: working version of an attribute driven cache Aaron Smuts wrote: > > I have a working version of the cache after converting it into an element > attribute driven system. It has disk spooling, disk defragmentation, remote > storage and synchronization, http lateral multicasting and direct lateral > deleting, cache regional specifications, global defaults, element > attributes, group and region element attribute defaults, session api like > group behavior . . . > > I had to take the system which was regionally defined and move the logic to > the element attribute level. I'm still cleaning it up. It needs an ant > make and the log needs to be moved to log4j. Later I can make distribution > and search like appenders that can be replaced. It isn't that flexible > right now, but is still composite in nature. Right now I'm working on > remote cache failover and clustering. . . > > Where should I send it? Put it up on a website and post the link here so we can take a peek at it :-) > > Aaron > > >> It seems like this would be a useful addition to Turbine. I can describe > >> what I have in mind in more detail if anyone is interested. > > >I don't know how I can say this clearly enough...BRING IT ON! :-) > > >-jon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tur...@ja... > For additional commands, e-mail: tur...@ja... -- jvz. Jason van Zyl jv...@ap... http://jakarta.apache.org/velocity http://jakarta.apache.org/turbine http://jakarta.apache.org/commons http://tambora.zenplex.org --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:28
|
-----Original Message----- From: Aaron Smuts [mailto:aar...@ve...] Sent: Saturday, June 09, 2001 11:35 AM To: tur...@ja... Subject: RE: working version of an attribute driven cache I'm very happy to hear that you are interested. There is talk of a separate cache project in the commons. If it is acceptable when I get it a little more flexible, then it should go wherever it makes most sense. You tell me. I thought the jgl libraries were some form of lgpl. At least in 96 they were. If not I'll just rewrite whatever we are using. http://www.objectspace.com/products/voyager/libraries.asp I'm probably not using javaclass.jar. I need to clean up. It is not necessary. The sun jars should probably not be distributed with this application. It shouldn't be a problem to put a turbine service wrapper around it. I'll look into it. A few things, if you are going to be testing it. The lateral distribution is not optimized, to put it mildly. I only use it for invalidation for non remotely configured caches. If necessary some sort of multicasting or tcp socket server with success messages and retries could be added fairly easily. I'm talking about making it into a pluggable framework, but there are some issues. Mainly, you can't control the behavior of elements by element properties if you don't know what will be there. The plugins would have to be typed neatly. If multiple plugins were provided, the majority of the control would move to the region -- specifying what types of lateral distribution, remote stores, etc. to use. The element attributes would then be behavior type description: whether the element is eligible for any type of lateral distribution or disk spooling or remote storage and retrieval. . . . There are basically 4 types of caches, memory, disk, distributed (1 way ), and remote ( distributed 2 way ). Each of these could be a plugin and there could be as many of each as the programmer wanted. The last two could function similarly, the search access sequence could just exclude those that do no searching and the implementations could just return null for those methods. The necessary conjunction between memory and disk is difficult to break. Perhaps the disk cache could be treated as a runoff cache. There could be stores, replicators, and runoffs. Talk to you later. Aaron -----Original Message----- From: Jason van Zyl [mailto:jv...@ap...] Sent: Saturday, June 09, 2001 1:53 AM To: tur...@ja... Subject: Re: working version of an attribute driven cache On 6/8/01 4:00 PM, "Aaron Smuts" <AS...@th...> wrote: >> Aaron, >> Have you talked to the guys in the commons project about the stuff they are >> doing on caching? >> James > > > Not really. They were talking about a cache project in the commons and > there was interest in the turbine group, so I'll send this to both places. > Sorry about the spam, but the topic overlaps. > > I updated the zip and added some java-docs with uml. > http://www.psoft.net/~asmuts/ > > Since a few people emailed me directly, I'll give a rough overview of the > caching system. > That is quite the beast :-) Looks incredibly comprehensive! I see in the lib/ you have several jars. Are all of these used, and if so what are the licenses that apply to each of these JARs? I don't know the fine details of the Sun JARs and I have no idea what the license is with JGL. JavaClass, or what is now BCEL is fine, and so are the rest. This would be a fabulous addition, were you thinking of implementing this as a Turbine service? This would be fantastic timing because I have separated out the service framework from Turbine. It's almost fully decoupled which means if you add your service to Turbine it will soon be available to a much wider audience, I hope :-) I would definitely like to play with this next week sometime so I can give you some useful feedback. -- jvz. http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:24
|
-----Original Message----- From: Aaron Smuts [mailto:aar...@ve...] Sent: Saturday, June 09, 2001 1:21 AM To: jak...@ja... Subject: cache discussion archive The cache I sent is a variation on the ocs4j cache that avoids the network clutter of primary lateral caches, the slowness of handling the difference between put and update, the cumbersomeness of coding around exceptions being thrown to signify expected situation ( eg. failed gets ). I started to implement the entire interface but found the overhead of the api tremendous. I never create a cache loader. It seemed unnecessary. About the memory maintenance algorithm. A simple lru implemented with a double linked list is most efficient and serves almost every need. Of course the memory cache should be pluggable. Each cache keeps tracks of local (ram hits, raf hits) and auxiliary hits (remote hits), misses, ram size, etc. We built into a production version a non element attribute version is in production while I finish this one ) a jetty server that will give remote cache stats, there is also a method of the cacheServiceAdmin interface that returns stats. > I think we're pretty much aiming at the same thing. I just want to keep the > public API nice and simple so it can be used anywhere (application, applet, > servlet, EJB) and has low dependency and can be either really simple (e.g. > just one LRUMap instance) or quite complex (using notification & messaging > systems, JMX, J2EE et al) with possibly hierarchial dependency tracking and > all sorts of other gizmos. It's fully configurable on a per region basis and then by element give the regional limitations. Later it will have a service framework. I described this briefly on the turbine-dev list. Take a look. Right now it is not pluggable. No major changes need to take place to make it so. It is pretty much interface driven, so substituting in a new package should be easy. The remote client will have to be moved out of the hub. We sacrificed a flexible pluggable structure for a fast configurable one. I now think we can have both give the general composite pattern followed. I'll get something like log4j up soon. http://www.psoft.net/~asmuts/ Oh, I used an old version of the cache, more simplified to manage Inside.com's content management system. We didn't have much hardware, so I replaced Vignette's junky storyserver caching with it and got much better performance. Now, at a real estate property management asp, I'm using a version that is regionally driven ( not elementally ) in a production environment with 10 web servers, 4 app servers, and 4 script servers, all of which are participating in some manor. We have full session failover across 10 machines. We could operate without a sticky loadbalancing and still function ( poorly ). ( The session folder in the zip is not what we are using. I converted the session stuff into the group cache and didn't make the session wrapper use the group cache yet. ) Remote cache hot standby support comes next. Aaron Re: [PROPOSAL] Cache project... ---------------------------------------------------------------------------- ---- From: James Strachan Subject: Re: [PROPOSAL] Cache project... Date: Fri, 18 May 2001 05:39:50 -0700 ---------------------------------------------------------------------------- ---- Hi Daniel From: "Daniel Hoppe" <ho...@si...> > I did not follow the ObjectPool discussions to closely, so I hope I'm not > missing the point. I didn't really follow the ObjectPool discussion either. > As far as I got it > > - the pool hands out an object exactly once. The object is unavailable for > others until it is returned > - the cache may hand out an object several times. The object is not > exclusively used. Thats my understanding too. In caching the same (read only) object is returned to all callers, rather than removing it per caller and putting it back again when they've finished with it. The two are quite similar from an implementation perspective but semantically quite different. There could be some potential sharing of common interfaces or implementation code across the two. > James, what do you think of making a cache JMX compliant? Sounds a great idea - particularly as the JMX compiance part could be a configurable, optional extra. I like the idea of being able to manage the cache & see whats being cached, per region, in different JVMs. I've never looked at JMX yet though. > I'm working on a > cache which is supposed to buffer data in a content management system. The > cache is supposed to store objects which are quite expensive, the caching > will be crucial for application performance. I've pretty similar needs & goals. Caching of expensive objects. (e.g. XML / XSLT documents for example). > That's why I need to have a > good overview on what's happening inside the cache, not just as some > debugging output but rather in a fashion that can be remote monitored and > integrated with monitoring tools. Agreed. > I plan to implement the measures > - objects in cache, > - cache hits, > - invalidations, > - cache misses of key that have not been in the cache yet, > - cache misses due to a constraint of maximum cache entries. > > The last two points might seem a little bit strange at the first thought, > but I think they can make a sense in certain situations. If a cache has the > option of either using soft references or a maximum number of entries, there > will be a certain amount of cache misses due to either a limited heap size > in case of soft references or a limited number of maximum entries allowed > (which is most probably related to heap size as well. Agreed. I'd like these kind of caching strategies and policies to be configurable at deployment, on a per region basis. Kinda like log4j has category based logging configuration, I'd like the same for caching. FWIW theres a SoftRefHashMap in the collections project too that might be useful. > With this monitoring information a sysadmin could easily determine if e.g. > an installation would benefit from an increased heap size. Agreed. > To distinguish between both types of cache misses it is of course necessary > - to keep a list of keys which are already known to the cache > - to have a mechanisim to finally drop keys after a certain while (e.g. the > key of a deleted page in a content management system should not remain in > the cache for weeks and months). > > This implies that the value object needs to have noticeably higher amount of > heap consumption and computation time on creation than the key, otherwise > the cache would of course not make much of a sense. > > In my current prototype I'm supplying three types of caches, a cache which, > when full, > > - drops the oldest value objects, > - drops the ones with the longest interim since the last hit > - drops the ones with the fewest number of total hits > > I can configure which kind of references are used (strong, soft, weak). > > I like the idea of a cacheloader. Thought of that as well, but somehow did > not have the drive to implement that in my ejb environment yet (might be > messy if the cacheloader has to deal with FinderExceptions of EJBs). I like the idea of the CacheLoader interface throwing exceptions, so it doesn't need to catch them then a cache region can decide what to do about it. (e.g. take down the cache, alert the JMX agent or whatever). > What I did not fully get so far is the idea of the cache-regions. I always > thought of putting a cache instance to some central location (Web > Application Context, JNDI Tree, e.g.), but maybe my view is to J2EE focused > on this. I'm a little bit sceptical about a cache being a static member as > there are some restrictions on that in the EJB spec.. Agreed. You can always use that lovely "transient" keyword ;-) A CacheRegion could be initialised & stored in a Web Application Context or JNDI tree if you like. The main idea behind the 'region' was to (a) avoid lookups to find it when it makes sense to do so and (b) allow per-region based configuration. Rather like log4j's categories, you might want to have different regions for different Java packages, or semantic names and so on. > Altold, do you think we are trying to achieve something similar or is my > approach too much heavy-wheight for your needs? I think we're pretty much aiming at the same thing. I just want to keep the public API nice and simple so it can be used anywhere (application, applet, servlet, EJB) and has low dependency and can be either really simple (e.g. just one LRUMap instance) or quite complex (using notification & messaging systems, JMX, J2EE et al) with possibly hierarchial dependency tracking and all sorts of other gizmos. James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---------------------------------------------------------------------------- ---- |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:21
|
-----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: Friday, June 08, 2001 4:01 PM To: tur...@ja... Cc: jak...@ja... Subject: RE: working version of an attribute driven cache >Aaron, >Have you talked to the guys in the commons project about the stuff they are >doing on caching? >James Not really. They were talking about a cache project in the commons and there was interest in the turbine group, so I'll send this to both places. Sorry about the spam, but the topic overlaps. I updated the zip and added some java-docs with uml. http://www.psoft.net/~asmuts/ Since a few people emailed me directly, I'll give a rough overview of the caching system. Very briefly: Right now the cache has 4 parts that can become plugable services: memory, disk, lateral, and remote [which has any combination of the others]. I'm going to make the central cache class into a hub with plugable services -- one-way and two-way stores: some for distribution and others for searching. I'd like to make a log4j like framework. The cache is divided into regions and supports in-region groups that provide the ability to associate and list grouped elements ( most useful for sessions ). Each cache element can be configured to expire, spool to disk, laterally distribute, and remotely synchronize with other caches if the overall regional attributes allow these behaviors. Elements are stored in memory in a double-linked list and spooled to disk using a simple lru algorithm. When objects are put in the cache they are laterally distributed if this option is on. The lateral cache is not intended for heavy use. It exists mainly for direct removal. Keeping items in synch and available when needed is up to the remote cache. The remote cache is updated with up-to-date copies of items in the local caches. Local caches can be configured to get items in a failure sequence. Generally a local cache will check memory then disk and then the remote cache before returning null. If an item is found remotely it is move to the local cache's memory cache. Local caches register themselves with the remote cache and when an element is put to the remote store, the remote servers notifies all listening local caches that the particular key is invalid. This avoids the network overhead of transmitting data that might not be needed. Each local cache adapts to the behavior patterns of it's users and doesn't force a memory list on the others. Also, with one remote store it is easier to keep the sequence of updates and invalidations in order. Obviously there are disk write locks, remote reestablishing background threads, mirrored attribute lists, and more detailed features to talk about. I'm still cleaning it up after the conversion. If jakarta isn't interested, please let me know. I need a repository and will just put it on sourceforge so I can work on it. Aaron -----Original Message----- From: James Coltman [mailto:jam...@ma...] Sent: Wednesday, June 06, 2001 12:53 PM To: tur...@ja... Subject: RE: working version of an attribute driven cache Aaron, Have you talked to the guys in the commons project about the stuff they are doing on caching? James -----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: 06 June 2001 17:06 To: tur...@ja... Subject: working version of an attribute driven cache I have a working version of the cache after converting it into an element attribute driven system. It has disk spooling, disk defragmentation, remote storage and synchronization, http lateral multicasting and direct lateral deleting, cache regional specifications, global defaults, element attributes, group and region element attribute defaults, session api like group behavior . . . I had to take the system which was regionally defined and move the logic to the element attribute level. I'm still cleaning it up. It needs an ant make and the log needs to be moved to log4j. Later I can make distribution and search like appenders that can be replaced. It isn't that flexible right now, but is still composite in nature. Right now I'm working on remote cache failover and clustering. . . Where should I send it? Aaron >> It seems like this would be a useful addition to Turbine. I can describe >> what I have in mind in more detail if anyone is interested. >I don't know how I can say this clearly enough...BRING IT ON! :-) >-jon --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:18
|
-----Original Message----- From: Aaron Smuts [mailto:aar...@ve...] Sent: Wednesday, June 06, 2001 11:04 PM To: tur...@ja... Subject: RE: url of cache -- RE: working version of an attribute driven cache There seems to be something wrong with my windows 2000 version of winzip (I can't open it on 98). I'll have a good file tomorrow. Sorry -----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: Wednesday, June 06, 2001 6:35 PM To: tur...@ja... Subject: url of cache -- RE: working version of an attribute driven cache Here you go. Sorry, the scripts are set up so the cache.zip must be unzipped in c:\dev\ and they have a hard coded javahome. I'll make something more user flriendly tomorrow. It will create a cache subfolder. I didn't include Unix test scripts in the bin. The run script starts the command line test program. The startRemoteCache.bat and stopRemoteCache.bat scripts do what they sound like. I had to borrow some web space: http://www.psoft.net/~asmuts/ Aaron -----Original Message----- From: Jason van Zyl [mailto:jv...@ap...] Sent: Wednesday, June 06, 2001 12:46 PM To: tur...@ja... Subject: Re: working version of an attribute driven cache Aaron Smuts wrote: > > I have a working version of the cache after converting it into an element > attribute driven system. It has disk spooling, disk defragmentation, remote > storage and synchronization, http lateral multicasting and direct lateral > deleting, cache regional specifications, global defaults, element > attributes, group and region element attribute defaults, session api like > group behavior . . . > > I had to take the system which was regionally defined and move the logic to > the element attribute level. I'm still cleaning it up. It needs an ant > make and the log needs to be moved to log4j. Later I can make distribution > and search like appenders that can be replaced. It isn't that flexible > right now, but is still composite in nature. Right now I'm working on > remote cache failover and clustering. . . > > Where should I send it? Put it up on a website and post the link here so we can take a peek at it :-) > > Aaron > > >> It seems like this would be a useful addition to Turbine. I can describe > >> what I have in mind in more detail if anyone is interested. > > >I don't know how I can say this clearly enough...BRING IT ON! :-) > > >-jon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tur...@ja... > For additional commands, e-mail: tur...@ja... -- jvz. Jason van Zyl jv...@ap... http://jakarta.apache.org/velocity http://jakarta.apache.org/turbine http://jakarta.apache.org/commons http://tambora.zenplex.org --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:16
|
-----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: Wednesday, June 06, 2001 6:35 PM To: tur...@ja... Subject: url of cache -- RE: working version of an attribute driven cache Here you go. Sorry, the scripts are set up so the cache.zip must be unzipped in c:\dev\ and they have a hard coded javahome. I'll make something more user flriendly tomorrow. It will create a cache subfolder. I didn't include Unix test scripts in the bin. The run script starts the command line test program. The startRemoteCache.bat and stopRemoteCache.bat scripts do what they sound like. I had to borrow some web space: http://www.psoft.net/~asmuts/ Aaron -----Original Message----- From: Jason van Zyl [mailto:jv...@ap...] Sent: Wednesday, June 06, 2001 12:46 PM To: tur...@ja... Subject: Re: working version of an attribute driven cache Aaron Smuts wrote: > > I have a working version of the cache after converting it into an element > attribute driven system. It has disk spooling, disk defragmentation, remote > storage and synchronization, http lateral multicasting and direct lateral > deleting, cache regional specifications, global defaults, element > attributes, group and region element attribute defaults, session api like > group behavior . . . > > I had to take the system which was regionally defined and move the logic to > the element attribute level. I'm still cleaning it up. It needs an ant > make and the log needs to be moved to log4j. Later I can make distribution > and search like appenders that can be replaced. It isn't that flexible > right now, but is still composite in nature. Right now I'm working on > remote cache failover and clustering. . . > > Where should I send it? Put it up on a website and post the link here so we can take a peek at it :-) > > Aaron > > >> It seems like this would be a useful addition to Turbine. I can describe > >> what I have in mind in more detail if anyone is interested. > > >I don't know how I can say this clearly enough...BRING IT ON! :-) > > >-jon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tur...@ja... > For additional commands, e-mail: tur...@ja... -- jvz. Jason van Zyl jv...@ap... http://jakarta.apache.org/velocity http://jakarta.apache.org/turbine http://jakarta.apache.org/commons http://tambora.zenplex.org --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:14
|
-----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: Wednesday, June 06, 2001 6:35 PM To: tur...@ja... Subject: url of cache -- RE: working version of an attribute driven cache Here you go. Sorry, the scripts are set up so the cache.zip must be unzipped in c:\dev\ and they have a hard coded javahome. I'll make something more user flriendly tomorrow. It will create a cache subfolder. I didn't include Unix test scripts in the bin. The run script starts the command line test program. The startRemoteCache.bat and stopRemoteCache.bat scripts do what they sound like. I had to borrow some web space: http://www.psoft.net/~asmuts/ Aaron -----Original Message----- From: Jason van Zyl [mailto:jv...@ap...] Sent: Wednesday, June 06, 2001 12:46 PM To: tur...@ja... Subject: Re: working version of an attribute driven cache Aaron Smuts wrote: > > I have a working version of the cache after converting it into an element > attribute driven system. It has disk spooling, disk defragmentation, remote > storage and synchronization, http lateral multicasting and direct lateral > deleting, cache regional specifications, global defaults, element > attributes, group and region element attribute defaults, session api like > group behavior . . . > > I had to take the system which was regionally defined and move the logic to > the element attribute level. I'm still cleaning it up. It needs an ant > make and the log needs to be moved to log4j. Later I can make distribution > and search like appenders that can be replaced. It isn't that flexible > right now, but is still composite in nature. Right now I'm working on > remote cache failover and clustering. . . > > Where should I send it? Put it up on a website and post the link here so we can take a peek at it :-) > > Aaron > > >> It seems like this would be a useful addition to Turbine. I can describe > >> what I have in mind in more detail if anyone is interested. > > >I don't know how I can say this clearly enough...BRING IT ON! :-) > > >-jon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tur...@ja... > For additional commands, e-mail: tur...@ja... -- jvz. Jason van Zyl jv...@ap... http://jakarta.apache.org/velocity http://jakarta.apache.org/turbine http://jakarta.apache.org/commons http://tambora.zenplex.org --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:14
|
-----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: Wednesday, June 06, 2001 12:06 PM To: tur...@ja... Subject: working version of an attribute driven cache I have a working version of the cache after converting it into an element attribute driven system. It has disk spooling, disk defragmentation, remote storage and synchronization, http lateral multicasting and direct lateral deleting, cache regional specifications, global defaults, element attributes, group and region element attribute defaults, session api like group behavior . . . I had to take the system which was regionally defined and move the logic to the element attribute level. I'm still cleaning it up. It needs an ant make and the log needs to be moved to log4j. Later I can make distribution and search like appenders that can be replaced. It isn't that flexible right now, but is still composite in nature. Right now I'm working on remote cache failover and clustering. . . Where should I send it? Aaron >> It seems like this would be a useful addition to Turbine. I can describe >> what I have in mind in more detail if anyone is interested. >I don't know how I can say this clearly enough...BRING IT ON! :-) >-jon --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:30:41
|
-----Original Message-----
From: Aaron Smuts [mailto:AS...@th...]
Sent: Friday, May 25, 2001 9:46 AM
To: tur...@ja...
Subject: RE: More on caching RE: Cache in Turbine and Velocity
If I can get a good start out there, the cache should be a completely
separate project. It is useful for other projects in the way a logging or
templating package is.
-----Original Message-----
From: James Coltman [mailto:jam...@ma...]
Sent: Friday, May 25, 2001 4:23 AM
To: tur...@ja...
Subject: RE: More on caching RE: Cache in Turbine and Velocity
Have you checked out the caching discussion that is currently going on in
the commons? If we can, I think working with those guys to get a project
neutral caching system is the way forward!!
James
-----Original Message-----
From: Aaron Smuts [mailto:aar...@ve...]
Sent: 25 May 2001 03:56
To: tur...@ja...
Cc: as...@th...
Subject: More on caching RE: Cache in Turbine and Velocity
In a template system it is nice to be able to control caching apart from an
expiration of time to live period. An interface to manually delete caching
is often helpful.
Oh, I'm almost done with a conversion of my caching sytem into somehting
closer to the ocs4j specification. There are a few issues and differences.
1. element vs region attributes:
My original cache was regionally defined. Each entry required a very
minimal wrapper. The osc4j spech is an element driven model where each
element is fully configurable. This could lead to a slight performance
penalty, but it is a richer model, where elements can inherit or have there
own attributes. So I'm converting the entire thing into element centered.
2. lateral broadcast vs. remote consitency
The oracle model is a laterally distributed model with no centralized
control. My model has the option for lateral braodcast ( which will need to
be made more efficient ) and a remote store that coordinates consitency.
Local caches send data to the remote store which then notifies other local
caches of changes to "regions" ( cashes ) that are registered. An update is
never broadcast from the remote only via the lateral caches if this is set
up. This way each local cache is a relatively separate realm with remotely
configurable regions that stay in synch without overriding the user habits
of a machine. If you broadcast changes to all servers then every server
must be ready for every user. The usage patterns of a user on one box can
effect the whole. With a remote store the local caches are primed to take
on similar patterns by talking to the remote store, but aren't flooded with
the elements form another machine. This significantly cuts down on traffic.
I'll work on ful lateral searching later, thought I don't think this is a
good model. Before that I'll build in the concept of failover. It should
be relatively simple to cluster the remote caches and create hot standbys.
3. put vs. replace
The difference between put and replace is not present in my cache by
default. The overhead associated is tremendous. There will be an alternate
"safe-put" method to deal with special caches.
4. nulls vs errors
If started to support ObjectNotFoudExceptions for failed gets but the
overhead and cumbersome coding needed to surroud a simple get method is
ridiculous.
5. cache loaders
I'm not supporting cache loaders at this time.
There are more but I don't have time and this probably isn't the place.
Since I'm making significant revisions the version I'll come out with next
week may seem to be a little ad hoc, but it can be improved with time.
I'll have something mid week for evaluation, but I'm not sure where to send
or put it.
Aaron
-----Original Message-----
From: Jon Stevens [mailto:jo...@la...]
Sent: Wednesday, May 23, 2001 3:48 PM
To: Turbine-user
Subject: Re: Cache in Turbine and Velocity
on 5/23/01 11:19 AM, "Sky Torch" <sky...@ho...> wrote:
> Hello,
>
> if same xyz.vm template is accessed twice, is it going
> to cached somewhere, i.e. the second request doesn't
> need the template to parsed again ?
>
> i guess it depends on service impl of that template
> in Turbine. if so, can someone point out what services
> are doing this, what not?
>
> also, if it does cache, it's using cache service to
> do this ?
There are several levels of caching you need to consider:
Template caching is handled by Velocity. Configure that in TR.props
through the Velocity Service configuration.
Module instance caching (ie: Screens, Actions, Layouts, Pages,
Navigations) is also configured in the TR.props file. Look for
module.cache I belive.
Template path's are also cached. In other words, Turbine does lookups to
find the right template to execute. This lookup is also cached. This is
also controlled in the TR.props file.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...
---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...
---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...
---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...
|
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:30:38
|
-----Original Message----- From: Aaron Smuts [mailto:aar...@ve...] Sent: Tuesday, May 15, 2001 8:26 PM To: tur...@ja... Subject: RE: Global Cache problem What if the cache checked for expiration when an element was retrieved. If a lazy date was used this wouldn't realy slow things down. The background process shouldn't eat up much of the processor though. The interval should be configurable? I'm working on an implementation of the ocs4j cache. Regions or caches can be defined and groups within regions can be controlled, for removal of related items. Partial retrieval (proto-liek queries are too difficult and slow ), however by group access is simple. Getting the keys in a group would be a simple matter, hence associated values could be pulled as needed. I'll have a possible solution in a week. Aaron -----Original Message----- From: jmcnally [mailto:jmcnally]On Behalf Of John McNally Sent: Tuesday, May 15, 2001 1:34 PM To: tur...@ja... Subject: Re: Global Cache problem Gareth Coltman wrote: > > Hi, > > I need to store lookup tables as I previously mentioned, and the > TurbineGlobalCacheService seemed perfect for this. > > My cache objects need to persist for the entire lifetime of the > application(ie from startup to shutdown), and this is what's causing > problems. > > 1. I can't work out how I can perform early initialisation - I need to load > database data into the cache on system startup. Services are the way to make sure you get early initialisation. Another simple way is to load the cache in a static initializer in a class that is used for accessing the cache. > 2. I want to stop the cache from constantly housekeeping. It's a waste of > processing for my application. There is a CachedObject.setTTL(-1) method that will stop the cleaning up of objects in the cache, but I do not know if it is possible to eliminate the housekeeping from at least looking for expired objects. john mcnally > > The other thing I would like is to divide my Cache into namespaces (or > different caches), so I can make the cache return all of a certain type of > element, without having to iterate through the entire cache. > > Has anyone else had to implement something similar? > > Gareth > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tur...@ja... > For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:30:37
|
-----Original Message----- From: Aaron Smuts [mailto:aar...@ve...] Sent: Sunday, May 13, 2001 5:27 PM To: tur...@ja... Subject: RE: cache Fantastic! I'm glad you're interested in the caching implementation. What are the steps to getting started? -----Original Message----- From: Jon Stevens [mailto:jo...@la...] Sent: Sunday, May 13, 2001 4:23 PM To: turbine-dev Subject: Re: cache on 5/12/01 10:59 PM, "Aaron Smuts" <aar...@ve...> wrote: > Are there any plans on implementing a system to keep share cached data > across multiple vm's and machines? The turbine cache looks like a local > cache without propagation or remote control. > > I've been working on and using a local remote caching system for a couple of > years that is very similar to the jcache proposal from Oracle. > > http://java.sun.com/aboutJava/communityprocess/jsr/jsr_107_cache.html Yup. I'm the "Apache" representation of this JSR which is actually quite lame because no one participates on the mailing list. > We've constructed a composite caching system that is configured like log4j > appenders. There are local memory, disk waterfall, rmi remote, and db > options for each cache group. I've used variations of the system at > inside.com to control to give the publishing system a centralized control. > I'm working on something similar for a property management asp to keep > semi-dynamic data in synch across 10+ web servers, app servers, and > scripting boxes. > > My team would like to build a new open-source system that might provide an > implementation of the proposed caching api. Without an open source > implementation the api will be really just be a description of Oracle9i. Yup. > It seems like this would be a useful addition to Turbine. I can describe > what I have in mind in more detail if anyone is interested. I don't know how I can say this clearly enough...BRING IT ON! :-) -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous <http://jakarta.apache.org/velocity/ymtd/ymtd.html> --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:30:31
|
-----Original Message----- From: Aaron Smuts [mailto:AS...@th...] Sent: Wednesday, June 06, 2001 12:06 PM To: tur...@ja... Subject: working version of an attribute driven cache I have a working version of the cache after converting it into an element attribute driven system. It has disk spooling, disk defragmentation, remote storage and synchronization, http lateral multicasting and direct lateral deleting, cache regional specifications, global defaults, element attributes, group and region element attribute defaults, session api like group behavior . . . I had to take the system which was regionally defined and move the logic to the element attribute level. I'm still cleaning it up. It needs an ant make and the log needs to be moved to log4j. Later I can make distribution and search like appenders that can be replaced. It isn't that flexible right now, but is still composite in nature. Right now I'm working on remote cache failover and clustering. . . Where should I send it? Aaron >> It seems like this would be a useful addition to Turbine. I can describe >> what I have in mind in more detail if anyone is interested. >I don't know how I can say this clearly enough...BRING IT ON! :-) >-jon --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:30:23
|
-----Original Message-----
From: Aaron Smuts [mailto:aar...@ve...]
Sent: Thursday, May 24, 2001 10:56 PM
To: tur...@ja...
Cc: as...@th...
Subject: More on caching RE: Cache in Turbine and Velocity
In a template system it is nice to be able to control caching apart from an
expiration of time to live period. An interface to manually delete caching
is often helpful.
Oh, I'm almost done with a conversion of my caching sytem into somehting
closer to the ocs4j specification. There are a few issues and differences.
1. element vs region attributes:
My original cache was regionally defined. Each entry required a very
minimal wrapper. The osc4j spech is an element driven model where each
element is fully configurable. This could lead to a slight performance
penalty, but it is a richer model, where elements can inherit or have there
own attributes. So I'm converting the entire thing into element centered.
2. lateral broadcast vs. remote consitency
The oracle model is a laterally distributed model with no centralized
control. My model has the option for lateral braodcast ( which will need to
be made more efficient ) and a remote store that coordinates consitency.
Local caches send data to the remote store which then notifies other local
caches of changes to "regions" ( cashes ) that are registered. An update is
never broadcast from the remote only via the lateral caches if this is set
up. This way each local cache is a relatively separate realm with remotely
configurable regions that stay in synch without overriding the user habits
of a machine. If you broadcast changes to all servers then every server
must be ready for every user. The usage patterns of a user on one box can
effect the whole. With a remote store the local caches are primed to take
on similar patterns by talking to the remote store, but aren't flooded with
the elements form another machine. This significantly cuts down on traffic.
I'll work on ful lateral searching later, thought I don't think this is a
good model. Before that I'll build in the concept of failover. It should
be relatively simple to cluster the remote caches and create hot standbys.
3. put vs. replace
The difference between put and replace is not present in my cache by
default. The overhead associated is tremendous. There will be an alternate
"safe-put" method to deal with special caches.
4. nulls vs errors
If started to support ObjectNotFoudExceptions for failed gets but the
overhead and cumbersome coding needed to surroud a simple get method is
ridiculous.
5. cache loaders
I'm not supporting cache loaders at this time.
There are more but I don't have time and this probably isn't the place.
Since I'm making significant revisions the version I'll come out with next
week may seem to be a little ad hoc, but it can be improved with time.
I'll have something mid week for evaluation, but I'm not sure where to send
or put it.
Aaron
-----Original Message-----
From: Jon Stevens [mailto:jo...@la...]
Sent: Wednesday, May 23, 2001 3:48 PM
To: Turbine-user
Subject: Re: Cache in Turbine and Velocity
on 5/23/01 11:19 AM, "Sky Torch" <sky...@ho...> wrote:
> Hello,
>
> if same xyz.vm template is accessed twice, is it going
> to cached somewhere, i.e. the second request doesn't
> need the template to parsed again ?
>
> i guess it depends on service impl of that template
> in Turbine. if so, can someone point out what services
> are doing this, what not?
>
> also, if it does cache, it's using cache service to
> do this ?
There are several levels of caching you need to consider:
Template caching is handled by Velocity. Configure that in TR.props
through the Velocity Service configuration.
Module instance caching (ie: Screens, Actions, Layouts, Pages,
Navigations) is also configured in the TR.props file. Look for
module.cache I belive.
Template path's are also cached. In other words, Turbine does lookups to
find the right template to execute. This lookup is also cached. This is
also controlled in the TR.props file.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...
---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...
|
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:30:21
|
-----Original Message----- From: Aaron Smuts [mailto:aar...@ve...] Sent: Sunday, May 13, 2001 2:00 AM To: tur...@ja... Subject: cache Are there any plans on implementing a system to keep share cached data across multiple vm's and machines? The turbine cache looks like a local cache without propagation or remote control. I've been working on and using a local remote caching system for a couple of years that is very similar to the jcache proposal from Oracle. http://java.sun.com/aboutJava/communityprocess/jsr/jsr_107_cache.html We've constructed a composite caching system that is configured like log4j appenders. There are local memory, disk waterfall, rmi remote, and db options for each cache group. I've used variations of the system at inside.com to control to give the publishing system a centralized control. I'm working on something similar for a property management asp to keep semi-dynamic data in synch across 10+ web servers, app servers, and scripting boxes. My team would like to build a new open-source system that might provide an implementation of the proposed caching api. Without an open source implementation the api will be really just be a description of Oracle9i. It seems like this would be a useful addition to Turbine. I can describe what I have in mind in more detail if anyone is interested. (I also want to know about task duplication in the scheduler when there are multiple instances of Turbine running.) Aaron --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
