VM Objects still there after hours/days on 1.NOVM.14 CONNECT-RETRY

Hello,

I was using 1.NOVM.18 on a linux 2.0.30 32Mo P-90 PC when one of the
cache users told me he couldn't accesss M$ site. I found out what the
problem was (thanks to this mailing-list) and I'm now using 1.NOVM.14
with the CONNECT-RETRY patch.

I was used to some VM Objects appearing during their download with
1.NOVM.18, but with the 14 patched there are now 32 of them (0 bytes
downloaded) in the VM for hours/days.
When I first saw the problem, I thought that many users were attempting
to view pages that were too slow to download, stopped to download it and
squid was still trying to download them because of slow transferts. I
modified my quick_abort in order to get rid of them : "quick_abort 1
0 0" instead of "quick_abort -1 0 0". But this wasn't any help:
there are still there, nobody downloading them and 0 bytes downloaded by
squid!

There are mainly URLs from www.microsoft.com, some of
espn.sportszone.com and (www.)altavista.digital.com. Only one from
messages.yahoo.com.

I noticed that only messages.yahoo.com doesn't have multiple IPs (at
this moment, maybe not when the object was requested...) So it could be
specific to squid patched with CONNECT-RETRY.

I would like to know if someone already observed such a behaviour with
squid NOVM, using/not using the CONNECT-RETRY patch.

Does someone know something about the same patch for 1.NOVM.18? If so,
where could I download it?

This problem could become urgent because Linux isn't patched for the
filedescriptors issue and squid is limited to 256 filedescriptors now.
So 32 objects is already a great amount for our cache.

Where could I find information on how to extend the maximum number of
filedescriptors per process, what the limit is for this maximum...

Thanks for your attention,

Lionel.
Received on Thu Dec 18 1997 - 19:50:36 MST