W3C home > Mailing lists > Public > www-jigsaw@w3.org > September to October 1997

Re: VERY IMPORTANT: Bug in getParent()

From: Alex Milowski <lex@www.copsol.com>
Date: Mon, 27 Oct 1997 10:38:10 -0600 (CST)
Message-Id: <199710271638.KAA01571@copsol.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:26 GMT