Re:How does DirectoryResource keeps its listing?

 > 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