W3C home > Mailing lists > Public > www-jigsaw@w3.org > July to August 1996

Jigsaw on Macintosh

From: Jeff Dripps <jeff@macalot.com>
Date: Sun, 7 Jul 1996 15:21:54 -0400
Message-Id: <v01510100ae0389c8ba09@[]>
To: www-jigsaw@w3.org
Hi Anselm,

I have spent the better part of last week reading about, tutorialing,
comparing, experimenting, crashing, and generally learning (and loving)
Jigsaw. During this time I have come up with two problems that I have ran
into, running Jigsaw on the macintosh platform. The problems described
below I have reliably reproduced on both 68K and PPC Macintosh. These
machines are running Apple's System 7.5.3 Revision 2 (which is, at this
moment, the latest system software release). These problems occur using
either Netscape Navigator version 2.0.1 or Netscape Navigator Gold 3.0b5
as the client browser.

Problem #1: It appears that Jigsaw manages data files by first creating a
temporary file (with a .tmp extension), then after updating the file
contents, attempts to rename the file to the desired name. The problem is,
at least on macintosh, this fails to occur for some reason. After
exercising Jigsaw, I find various files scattered about, such as
realms.db.tmp, admin.db.tmp and many .jigidx.tmp files. It appears that
Jigsaw could not rename them for some reason (possibly because they are
open?). In any event, this does not appear to be due to a duplicate file
name, as in many cases there was no such file.

For example, when I attempted to add a realm for the first time, as
described in the authentication tutorial, it appeared as though everything
worked just fine. However, when I restarted the server, the realm
disappeared. Upon checking the server, the file 'realms.db.tmp' existed on
the machine, as did admin.db.tmp, but no renaming of these files took

Furthermore, when I physically renamed 'realms.db.tmp' to 'realms.db', lo
and behold everything worked fine, until I attempted to add another new
realm. Once again the 'realms.db.tmp' file was created (containing the
additions I had just made) but this time the 'realms.db' was not destroyed
and 'realms.db.tmp' was never renamed to take it's place.

The above event sequences generate the following errors in trace mode:

[w3c.jigsaw.resources.SimpleResourceStore@./config/auth/admin.db]: unable
to rename ./config/auth/admin.db.tmp to ./config/auth/admin.db
[w3c.jigsaw.resources.SimpleResourceStore@./config/realms.db]: unable to
rename ./config/realms.db.tmp to ./config/realms.db
        at w3c.jigsaw.http.Client.getNextRequest(Client.java)
        at w3c.jigsaw.http.Client.loop(Client.java)

And in the errlog:

<httpd>: [httpd][restart]: inited !<c1;client1>: caught exception
[java.lang.NullPointerException] null<c0;client0>: caught exception
[java.lang.NullPointerException] null<httpd>: [httpd][shutdown]:

Problem #2: Rarely will Jigsaw ever finish sending a lengthy html page (or
the browser somehow is missing the last block??). For example, the URL:
will rarely finish. It gets to 90-99% and just hangs, as though the browser
is waiting for one more block.

This is the trace output when this occurs:
        (while the 'stopsign' remains enabled in Netscape).

[raw   ]connection=Keep-Alive
[raw   ]referer=http://cc3.ccia.com:9999/
[raw   ]host=cc3.ccia.com:9999
[raw   ]accept=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
[raw   ]user-agent=Mozilla/2.01 (Macintosh; I; PPC)
[raw   ]connection=Keep-Alive
[raw   ]referer=http://cc3.ccia.com:9999/User/Tutorials/configuration.html
[raw   ]host=cc3.ccia.com:9999
[raw   ]accept=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg
[raw   ]user-agent=Mozilla/2.01 (Macintosh; I; PPC)

At this point the document is still incomplete, yet if you continue to
wait, eventually the (persistant) socket in Jigsaw times out and the
following trace output appears:

w3c.jigsaw.http.HTTPParserException: Couldn't parse the request: expecting
(32) got (-1)

Immediately at this output, Netscape puts up a dialog box complaining of a
'broken pipe' error. (It seems here that, Netscape is still expecting to
read content, but Jigsaw felt that all content was sent and acknowledged
and has closed the socket.) In any case the following trace output, follows
the dismissal of the Netscape dialog box:

at w3c.jigsaw.http.HTTPParser.getRequest(HTTPParser.java)
        at w3c.jigsaw.http.Client.getNextRequest(Client.java:261)
        at w3c.jigsaw.http.Client.loop(Client.java:496)
        at w3c.jigsaw.http.Client.runConnection(Client.java:572)
        at w3c.jigsaw.http.Client.run(Client.java:555)
        at java.lang.Thread.run(Thread.java:289)
w3c.jigsaw.http.ClientException: Couldn't parse the request: expecting
(32) got (-1)

        at w3c.jigsaw.http.Client.getNextRequest(Client.java:265)
        at w3c.jigsaw.http.Client.loop(Client.java:496)
        at w3c.jigsaw.http.Client.runConnection(Client.java:572)
        at w3c.jigsaw.http.Client.run(Client.java:555)
        at java.lang.Thread.run(Thread.java:289)

In a previous message, it was suggested that I attempt to disable
persistant sockets, to see if that would indicate any difference in regards
to this problem of premature connection closure. According to this
suggestion, I have attempted to run Jigsaw with Keep-Alive set to false.
The only difference then is, there is no delay before the broken pipe
dialog is presented, as there is when using a persistant socket. That is,
as soon as Jigsaw closes the socket at the end of the document, the dialog
complaining of a broken pipe error is immediately displayed, even though
the document still is incomplete (usually by 50-600 bytes).

If there is anything else I can do to help track down and correct these
problems, please don't hesitate to ask! Any and all suggestions would be
appreciated. sinc, -jeff
Received on Sunday, 7 July 1996 21:36:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:29 UTC