Article delegate-en/4414 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A4407@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Delegate with NFS cache spool
16 Mar 2009 11:32:20 GMT Eddie Stassen <pcqiqbdyi-qjyh54kxctxr.ml@ml.delegate.org>


Hi Yakuta,

Thank you very much, it works perfectly now!

Regards,
Eddie

Yutaka Sato wrote:
> Hi Eddie,
>
> Thank you for the detailed information.  It seems that the problem is caused
> because feof() does not become true on ESTALE in getc(), so fgetsZ() does
> not return NULL, then it is retried endlessly.  I could reproduce it on my
> machines (so far on Solaris10 and FedoraCore6) and it was fixed as the
> enclosed patch to fgetsZ(). 
>
> In message <_A4405@delegate-en.ML_> on 03/11/09(17:02:30)
> you Eddie Stassen <pcqiqbdyi-qjyh54kxctxr.ml@ml.delegate.org> wrote:
>  |> In message <_A4372@delegate-en.ML_> on 02/20/09(23:17:57)
>  |> you Eddie Stassen <pcqiqbdyi-qjyh54kxctxr.ml@ml.delegate.org> wrote:
>  |>  |We are running delegate as a caching proxy NNTP server (on Solaris 10) 
>  |>  |using NFS mounted drives as a cache spool.  Now and then we find 'stuck' 
>  |>  |delegated processes which take up a lot of CPU cycles.  Running truss, 
>  |>  |it appears that the process is getting an ESTALE error when reading from 
>  |>  |the spool (not sure why this is, possibly a file deleted while it was 
>  |>  |being read), however it seems  delegated is ignoring the error and 
>  |>  |sitting in a tight loop continuously retrying to read.  I have had a 
>  |>  |look through the source code to try and figure out where this is 
>  |>  |happening, but without much success so far.
>  |>  |
>  |>  |Could you perhaps have a look and see if a fix could be made, or perhaps 
>  |>  |point me to the correct place in the code so I can make a temporary hack?
>  |>
>  |> The first step should be locating where it occurs.  The output of
>  |> truss might imply where it is.  Or you can inspect the process
>  |> with mdb for example as "mdb -p ProcessId" and dump the calling
>  |> stack with the "$c" command.
>  |>
>  |>   
>  |I have managed to get the following information which might help to 
>  |pinpoint the problem.
> ...
>  |$ pstack 26448
>  |26448:  /opt/local/news/delegate-test/sbin/delegated +=/opt/local/news/delegat
>  | ff04a748 _read    (41daa8, 3a31f0, a9, 0, 43c124, ffbb7fb8) + c
>  | 0024be60 _Z6fgetsZPKciS0_iS0_iP6__FILE (32b730, 193, ffbb7bb8, 400, ffbb7bb8, ffbb7fb6) + 21c
>  | 0028f304 _Z8fgetsTeePKciS0_iS0_iP6__FILES2_S2_i (32b730, 402, ffbb7bb8, 400, ffbb7bb8, 400) + 134
>
> Cheers,
> Yutaka
> --
>   9 9   Yutaka Sato <y.sato@delegate.org> http://delegate.org/y.sato/
>  ( ~ )  National Institute of Advanced Industrial Science and Technology
> _<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
> Do the more with the less -- B. Fuller
>
>
> *** dist/src/delegate9.9.2-pre7/rary/String.c	Mon Mar  2 14:04:36 2009
> --- ./rary/String.c	Wed Mar 11 21:18:52 2009
> ***************
> *** 2583,2588 ****
> --- 2583,2591 ----
>   	setVStrEnd(sp,0);
>   	if( sp == str && feof(fp) )
>   		return NULL;
> + 	if( sp == str && ch == EOF ){
> + 		return NULL;
> + 	}
>   	return str;
>   }
>   int fputsZ(PCStr(str),FILE *fp){
>   

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V