On Saturday, January 27, 1996 at 1:01:44 am CET,
Jeff Kell <[log in to unmask]> wrote:
>Thanks to a private message I received from an httpd 1.3 user (I won't
>disclose the source since I don't have his permission at this point)
>we appear to have another point to consider with httpd 1.3 on the 3000,
>so any sites running the software take note (I haven't had time to update
>the web page FAQ, nor do I have all the details, but this *is* serious).
 
I was the one reporting this problem to Jeff.
 
>He reports that httpd is consuming timer entries in the system tables.
>His report was a bit vague about the details (I was waiting on a reply from
>him before posting this, but since I've received no word yet, it seemed to
>be important enough to bring it to your attention); hopefully he will
>followup to the list with more specifics.
>In short, running httpd over time (without rebooting) consumes timer entries
>due to fault in TERMINATE not returning some entries back to the free list.
>If the timer entry table is exceeded, kaboom, System Abort.
 
HP Netherlands helped us to identify it as an error in TERMINATE. TERMINATE
does not (always) clear the entries in the timer request list that are not
explicitly deallocated by the program.
The SR number for the timer problem is 1653-157107.
 
>To check to see if you have the problem (if you're running httpd) you can
>use Threshold Manager (thmgr.pub.sys), enable it if necessary, then display
>the entries and look at the timers value.  I found one of our sites already
>at 75% (after only a week of operation).  Restarting httpd appears to have
>no effect, you have to reboot the system to recover the timer entries.
 
We, the Agricultural University Library of Wageningen, the Netherlands, are
running a well visited server and it took us about 8 days before the system
aborted. (http://www.bib.wau.nl)
 
>He has a "workaround" to place alarm(0) calls at strategic points in the
>code, but he didn't elaborate on exactly where.  One of us will follow-up
>on the details and I will apply the patches to at least the opus source
>distrubition when I get specifics.
 
Apart from being an error in TERMINATE, it is also an error in the
application, of course. Therefore we located all alarm() calls with a nonzero
argument and checked whether there were corresponding calls with a zero
argument. For the three occurrences we found, we inserted alarm(0) calls just
before leaving the function that contained the original call.
We also inserted one in the signal handlers used by these functions (one of
which is for SIGALRM !). Source modifications has been send to Jeff, who will
be so kind to apply them to his version for downloading.
 
We also ran into another problem with the httpd-server on the HP3000.
It causes network errors (at least, this is how Netscape is calling them).
Most of the time it's causing small files like gifs of buttons, not to be
displayed, Netscape shows the 'broken picture' symbol. We noticed in the
network traffic that the HTTPD reports NOT MODIFIED to the client after a
request about the modification is send to the server. The client somehow does
not receive or misinterprets the response. It only happens for files, cached
by the client. Once memory cache and disc cache are set to zero, the problem
does not happen again. We think it is a timing problem. The HP is sending a
packet saying the file is not modified, immediately followed by a R-packet,
not waiting for the confirmation of the receipt of the packet send before.
I have tried to create the same faults with the JAZZ server, but it's not
easy. I only once succeeded to get this fault. The responses of this server
are being received much slower ofcourse. We also think that faster PC's do
not experience this problem as often. I never experience these problems with
other servers. Unfortunately I don't know of any dutch HP3000's that are
running the HTTPD server.
Regards,
Peter
=============================================================
Drs. Peter J.C. van Boheemen
Head Systems Development and Data Base Management
LIBRARY WAGENINGEN AGRICULTURAL UNIVERSITY/PUDOC-DLO
Jan-Kopshuis, Automation Department
tel: +31-8370-82517                       fax: +31-8370-84761
Email: [log in to unmask]
Snail:Gen. Foulkesweg 19, 6703 BK Wageningen, the Netherlands
http://www.bib.wau.nl/people/peter.html