- From: Anselm Baird-Smith <abaird@w3.org>
- Date: Sun, 23 Jun 1996 20:48:26 +0500
- To: alex@access.com.au (Alexandre Rafalovitch)
- Cc: www-jigsaw@w3.org
> Ok. Let me see if I got it. > > I try to access directory /foo. New DirectoryResource is created and it > create a local variable with a listing in it. The listing var is initially empty. It gets computed only on demand (eg when a GET request reaches the directory resource). The point is that you compute the listing only if needed. > Next, I try to access directory /bar. Another DirectoryResource is created > and it gets its local variable with a listing. > Next, I try to access directory /foo again. At some point during lookup > (?), it is realised that we already have a DirectoryResource corresponding > to /foo, and it is called. This existing directory resource returns listing > that was stored in local variable. Nearly correct. As I said above, only the first time you access foo will the listing be created, so: "I try to access foo again, during lookup it is realized that we already have ... and it is called. The directory GET methods gets called, and it looks for a directory listing (getDirectoryListing). This method will either: a) compute a fresh directory listing (if listing was null before) b) check that the current directory listing is still valid (or recompute one if needed) In both cases the directory listing is stored in 'listing' and sent back as a reply. > Some time later (when), the instance is released and it is garbage > collected. If /foo is referenced again later, we have to create new > instance again. When the ResourceStoreManager decides it is time to do so (when it detects that free memory is getting low), it starts up the ResourceSweeper thread. This thread will go through all existing *resource store* starting with the one that has been least recently used. For each resource store the sweeper sends a notification of low memory, at which time the store has the ability to remove from memory the resource it thinks it is usefull to get rid of. The resource store has several options: a) it maintains its own LRU list of resources,, in which case it goes through resources freing them from memory b) it knows that only a few resource in the store consumes a lot of memory, it can get rid of those c) it can implement any otyher fancy thing it wants, it can even pass the hand (if it thnks that even its resources have not been accesssed recently, getting rid of them would be costly). The sweeper thread itself continue to go through the resource store list until it find that memory requirements are met again. NOTE: As java doesn't provide any real mean of knowing how low the free memory is, the current ResourceStoreManager maintains a limit on the number of resource store loaded, which is currently used as an indication of how much memory the Jigsaw process consumes. This is a bad approximation, but it can't be fixed without changes in the Java APIs. (I am quite confident this will happen, as Jeeves will hopefully requires the same API). > We cannot reuse existing instance by reinitializing it, we have to create > new one, and let old one be garbage collected (no resource pools in here?) Resource that gets freed by the above process are pickled to disk (in the .jigidx file) before being freed from memory. This mean that the resource configuration itself is nevcer lost. When a freed resource is hitted again by a request, it is loaded' from the .jigidx again, and initialize (through a call to initalize (Object args[])). > Am I right and I can use any locals as far as I know they can dissapear at > any time? Is there any way to keep information in locals for as long as I > can and then just before unloading, write it to the file? Yes local can disappear at any point of time. The resource will be notified (through a call to notifyUnload) before it disappear back to disk. If you want to make your local persistent, then you have to declare them as attributes of the resource, using the AttributeRegistery (the spelling eror will be corrected in next version). For some insight of how to use attributes, you can either look at the resource tutorial (/User/Tutorials/resource.html), or read the code. The w3c.jigsaw.resources.FileResource, for example, declares a number of attributes. Accessing attribute value is a little slower then accessing local variables, but I did my best to make it as efficient as possible (on the order of accessiong an object in an Object[]). > Thank you, > Alex. > > Ps. What are the plans for the next version? I could not find any > information on it on w3c pages. Anselm, can you give us estimates. > PPs. If you can give us estimates, can you send it as a separate message, > so other people could find it easily between other mails. I'll try to do this, for the time being, I will be concentrating on making Jigsaw 1.1 compatible, and implementing a caching proxy server. I hope to hav this ready by the end of July. Anselm.
Received on Sunday, 23 June 1996 20:48:35 UTC