- From: Alex Milowski <lex@www.copsol.com>
- Date: Mon, 27 Oct 1997 10:38:10 -0600 (CST)
- To: www-jigsaw@w3.org
Hello all again! It is confirmed! The directory resource (the parent) was getting unloaded and then the next access to the child resource would fail with the stack trace that you see below related to another problem identified (see below). This seems to be a bug to me. > I think I have found a bug in getParent() that should only appear in, well, > my code! It is a very serious problem if I am correct. <snip> > A work aroung I have thought of is: > > We already have a special indexer setup. Create our own directory > resource that *never* gets unloaded. There just aren't that many > directories in our system. Hence, parent will never get unloaded. This helps. If you do this, they the get()/etc. works. Unfortunately, I think there is something seriously wrong. Now, the get returns but the next get to the same resource or any other resource (including root) generates the following stack trace: GET /dds/coordinator.ashtml?Admin HTTP/1.0 Connection: Keep-Alive Date: Mon, 27 Oct 1997 15:53:48 GMT Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Language: en Host: tiger Referer: http://tiger/dds/coordinator.ashtml User-Agent: Mozilla/4.03 [en] (WinNT; I) +++ client-1(socket-clients:20) got exception: java.lang.NullPointerException: at w3c.tools.store.AttributeHolder.getValue(AttributeHolder.java) at w3c.tools.store.Resource.collectFrames(Resource.java) at w3c.jigsaw.resources.FilteredResource.getFilters(FilteredResource.jav a) at w3c.jigsaw.resources.ContainerResource.lookup(ContainerResource.java) at w3c.jigsaw.resources.StoreContainer.lookup(StoreContainer.java) at w3c.jigsaw.http.httpd.perform(httpd.java) at w3c.jigsaw.http.Client.processRequest(Client.java) at w3c.jigsaw.http.Client.startConnection(Client.java) at w3c.jigsaw.http.socket.SocketClient.run(SocketClient.java) at w3c.util.CachedThread.run(ThreadCache.java) w3c.jigsaw.http.ClientException: at w3c.jigsaw.http.Client.startConnection(Client.java) at w3c.jigsaw.http.socket.SocketClient.run(SocketClient.java) at w3c.util.CachedThread.run(ThreadCache.java) java.lang.NullPointerException: at w3c.tools.store.AttributeHolder.getValue(AttributeHolder.java) at w3c.tools.store.Resource.collectFrames(Resource.java) at w3c.jigsaw.resources.FilteredResource.getFilters(FilteredResource.jav a) at w3c.jigsaw.resources.ContainerResource.lookup(ContainerResource.java) at w3c.jigsaw.resources.StoreContainer.lookup(StoreContainer.java) at w3c.jigsaw.http.httpd.perform(httpd.java) at w3c.jigsaw.http.Client.processRequest(Client.java) at w3c.jigsaw.http.Client.startConnection(Client.java) at w3c.jigsaw.http.socket.SocketClient.run(SocketClient.java) at w3c.util.CachedThread.run(ThreadCache.java) Sometimes it seems to work for awhile and then it fails consistently with the above. This is the same behavior that I saw when the parent resource was unloaded. The root resource is still an instance of w3c.jigsaw.resourecs.DirectoryResource and, thus, can still be unloaded. Most likely, it is being unloaded. Shouldn't the root resource *never* be unloaded? To me, without recompiling jigsaw without optimization to get the line numbers, it seems that the root resource is in an invalid state. Is it possible for the root resource to get unloaded yet still have something else (a thread?) having a reference to it? We could replace all directories in jigsaw with our "new and improved" directory resource, but that seemsj like a large workaround for a bug. Here's my plan: 1. Recompile jigsaw to get the line numbers to ensure that it is indeed generating the exception where I think it is. 2. Hack a notifyUnload() method into directory resource to see if the root resource gets unloaded between accesses. 3. If so, we have a "work around" by making directories unloadable. 4. Plea for "those in the know" to provide a proper fix. I'll start with a plea and move to begging and groveling (sp?) if I have to! ;-) Again, am I bonkers or am I on the right track? What doesn't seem right here is that Jigsaw has been stable for us for so long. We switched to the 1.0 beta 1 immediately when it became available. Although that was weeks ago, are there changes that could have caused this? Also, as a design issue. It would seem that as long as a resource is loaded, that resources's ancestory (parent-child relationship to root) should be loaded. This seems like a valid restriction on unloading. When Jigsaw goes to unload a resource, it should check to see if it is an instance of ContainerResource and check to see if any children are loaded. If they are and can be unloaded, do so. If the children cannot be unloaded, the ContainerResource instance should not be unloaded. Sound reasonable? ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608
Received on Monday, 27 October 1997 11:41:39 UTC