RE: Release Schedule

> > > in a ufs-style FS, the data may come back in chunks since
> the object
> > > is big, but if the object is a small image it'll come back
> > > in one chunk.
> >
> > Ok. I second this then.
> > It would be best if there was some kind of pressure on the
> chunk size:
> > when RAM becomes scarce decrease the chunking. If we go out of core
> > performance is going to be horrible anyways.
>
> My aim is to have a NOVM type squid with COSS - I can always
> modify the
> OS idea of caching, and possbly add some "hinting" in Linux/FreeBSD
> for performance.

/me doesn't know NOVM, sorry.
But I think I understand, and I agree.

> > > There's some magic with the SM_PAGE_SIZE size in the
> code, and there
> > > was even before I got to it. the CLIENT_MEM_SOCK_BUF is also 4096
> > > bytes and when I tried upping it a while back things fell over.
> >
> > We can keep it as a basic block, shouldn't be a problem to
> temporarily waste
> > a few k's.
>
> Right. Well, I'm going to kill that very soon. The code shouldn't rely
> on it being 4096 bytes. :-)

4096 bytes is quite dumb actually, because when you add malloc overhead, it
becomes
more likely than not two pages, or 8k on i386 (wee! 50% overhead!).
The basic idea IMO is that it CAN
be chunked, but (maybe) the chunk should be defineable somewhere, maybe at
build-time, and it should not be on 1k boundaries unless we use a slab
allocator
to reduce malloc overhead.

> > Worse than that. I'm using the sourceforge ntlm-tag (which
> is better than
> > what I'm running now in production, a
> 2.4-DEVEL3-NTLM-worse-than-hell).
> > Unfortunately it can't be avoided. I _HAVE_TO_ properly
> implement NTLM
> > authentication NOW.
> > On the plus side, Aug 10 ntlm branch has faitfully served
> over 5.5 million
> > hits
> > over 10 days (before crashing, but I try not to think to that).
>
> *laugh* WHat did it crash on? :)

Heh. Robert and I have been chasing ghosts in the past 2 months. First
there was an obscure hashtable corruption bug which crashed squid when
somebody logged in with basic auth AND used upper-case chars.

The current problem is a known bug in NTLM, where in heavy-load situations
(like the ones I'm going to get - in excess of 200 hits/sec), after some
random time squid starts "leaking" NTLM AUTHENTICATION helper processes.
I was using 10 processes, and after 5.5Mhits, squid had lost all of them.
It could not authenticate anymore, a queue filled up too much and squid
crashed (notice: it's not a problem of squid crashing, that is a correct
behaviour. The problem is that it shouldn't leak helper processes).

> > > This is really starting to irk me somewhat. I'd suggest
> > > either creating
> > > a 2.5 branch for you guys to keep doing NTLM stuff on, or
> force you
> > > two to MFC the NTLM and auth code back to squid-2.4.
> >
> > No way to do that. Auth-changes are way to wide.
>
> Ok. Perhaps we should branch off squid-2.5 soon?

I second that completely.

> > > I note that more and more people on squid-users are using
> squid-2.5
> > > in production, and its rather scary for the developers. Well, at
> > > least me. :-)
> >
> > It is scary, and I am scared (but somewhat happy because
> this means that we
> > get more meaningful bugreports) :)
> > Maybe it really is time to freeze 2.5 and short-schedule
> COSS and aio and
> > similar for a 2.6 to follow 2.5 by a couple of months?
>
> The question is getting 2.4 and 2.5 out the door. I still think we
> should just tag stable2 with how the squid-2.4 branch looks now.
> I then think we should just branch 2.5. Its messy, but I don't see
> any other option. I think 2.5 has the options in it that we targeted
> a while back on the squid-dev list.
> Ok. Here's my vote:
>
> * tag squid-2.4stable2
> * branch the squid-2.5 branch
> * tag squid-2.5devel1
>
> Once 2.5 has been tested a little more widely we can stuff
> squid24 into
> maintanence mode and concentrate on making 2.5 rock solid,
> whilst working
> on new features for 2.6 .
>
> Any other votes? Duane, Henrik, Robert?

For what my vote is worth, I second your ideas.

-- 
	/kinkie