On 19/09/17 12:45, Eliezer Croitoru wrote:
Hey All,
In the last 2 year I have tested Squid-Cache 3.5 and for general purposes
and it's stable.
The basic challenge is a simple internal traffic but there are couple other
challenges which I would like to verify.
The first thing is a test of squid against a very hostile environment like
the public Internet.
By testing on the public Internet I mean that it will sit in intercept or
trproxy mode ontop of a "VPN" service.
I believe that such a test would benefit us with more details about the
stability of the 3.5 branch and later maybe test the 4.x branch.
There are some legal issues in running such a setup and I would not be able
to run such a setup without some valid usage agreement.
First what do you all think about the idea in general?
We have various people actively using the latest code of both the v5 and
v4 series. So Squid code of all branches is already being run in various
production situations. Its just that since they are commercially
sensitive we do not get feedback unless things actually go wrong.
Second, would we be able to somehow list the known 3.5 bugs?
Each Squid series wiki page links to the bugzilla report listing all
bugs which are still open and affecting that release.
eg <https://wiki.squid-cache.org/Squid-3.5#Open_Bugs>
I believe that such a list will help the admins to decide if Squid-Cache is
for them or not.
Currently there are 574 open bugs on the Bugzilla and maybe some of these
are not even relevant to 3.5.
-
http://bugs.squid-cache.org/buglist.cgi?bug_status=__open__&content=&limit=0
&no_redirect=1&order=priority%2Cbug_severity&product=Squid&query_format=spec
ific
Amos, You have suggested to walk me through some of the bugs to make our
lives much easier.
And I was thinking for example this bug: 3.2.1 SEGFAULT while freeing
ipcache_entry
http://bugs.squid-cache.org/show_bug.cgi?id=3644
It's a Solaris based squid which appeared in 3.2 and was confirmed by the
reported as "works for me" but never been marked this way.
If I'm not wrong Yuri also works or worked with solaris and can verify if
this kind of a bug exists or not on 3.5 can then we can close it as "works
for me".
More correctly it disappeared without anyone making changes. So may
recur at any time.
There have been some major changes to the memory management and safety
since that version, but not so much in terms of ipcache improvements
except indirectly through libmem / MEMPROXY pool changes.
The uncertainty there means leaving it open until more certainty happens
just in case it does recur.
Also this bug: PURGE not purging hot objects (TCP_MEM_HIT ) with
memory_cache_shared on
http://bugs.squid-cache.org/show_bug.cgi?id=3888
Which I have seen that some work is being done on github to resolve this
bug(3888)
It's there for at-least 3 years but nobody changed the milestone to what so
version.
I upped up the milestone to 3.5 since any patch will not be created by the
squid project itself to older versions then 3.5 ie .3.4 and down.
If you think that the milestone is 5 or 4 please change accordingly.
The milestone needs to be set to the oldest version where the bug is
known to be *fixed*. So the report in the wiki page can accurately list;
for example that this bug is still affecting Squid-4.
If we do not have a) a patch applied to the code master branch and
working its way down to whatever old version, or b) a confirmation that
the bug is gone in latest code; then the milestone should stay unset.
Eduards patch is expected to get to v4 but not older, so it will
eventually be milestone of v4 not v3.5.
Amos
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
