On Thu, Nov 22, 2007, Henrik Nordstrom wrote:
> On tor, 2007-11-22 at 10:57 +1300, Amos Jeffries wrote:
>
> > Three cheers for Henrik! :-)
> >
> > Any chance of a 3.1 port soon?
>
> We need a bit of discussion on whats the best approach on how to solve
> Bug #7 first.
>
> I.e. should we do like
On tor, 2007-11-22 at 10:57 +1300, Amos Jeffries wrote:
> Three cheers for Henrik! :-)
>
> Any chance of a 3.1 port soon?
We need a bit of discussion on whats the best approach on how to solve
Bug #7 first.
I.e. should we do like I did for Squid-2, rewriting the entry, or should
we jump directl
On Thu, Nov 22, 2007, Amos Jeffries wrote:
> The code itself maybe. However the side-effects of using it should be
> checked and tested well.
> I believe the data is buffered by the kernel on receipt to a large degree
> these days, whether the client app reads it out or not. Throttling the
> inbou
> On Wed, Nov 21, 2007, German Gomez wrote:
>> Hello,
>>
>> I've reading through the list and found several references to this
>> subject, how to limit bandwidth for cached content, and the only
>> solution
>> was to use QOS inside linux kernel. We have a remote accelerator proxy
>> and would like
On Wed, Nov 21, 2007, German Gomez wrote:
> Hello,
>
> I've reading through the list and found several references to this
> subject, how to limit bandwidth for cached content, and the only solution
> was to use QOS inside linux kernel. We have a remote accelerator proxy
> and would like to limi
Hello,
I've reading through the list and found several references to this
subject, how to limit bandwidth for cached content, and the only solution
was to use QOS inside linux kernel. We have a remote accelerator proxy
and would like to limit the bandwith for big files so smaller ones get
disp
> hno 2007/11/21 06:44:29 MST
>
> Modified files:
> src Makefile.am Makefile.in client_side.c
> protos.h
> Added files:
> src store_update.c
> Log:
> Bug #7: Update stored headers with headers from 304 responses
>
>
> >
> > Sounds like a data access problem. This is a killer bug (pun intended).
>
> I'm not seeing any crash here.
> To my untrained eye it looks like its working. :-)
>
But not in the intended way:-(
We should watch somewhat like :
SNMPv2-SMI::enterprises.3495.1.4.1.1.1.64.233.183.99 =
On Wed, 2007-11-21 at 21:12 +1300, Amos Jeffries wrote:
> Rafael Martinez (Squid development) wrote:
> >> If snmp_core.cc revision 1.10.8.26
> >>
> >> How can I come back into 1.10.8.24 ?
> >>
> >
> > cvs update -j 1.10.8.26 -j 1.10.8.25 snmp_core.cc
> > cvs update -j 1.10.8.25 -j 1.10.8.24 snmp
On Wed, 2007-11-21 at 21:12 +1300, Amos Jeffries wrote:
> Rafael Martinez (Squid development) wrote:
> >> If snmp_core.cc revision 1.10.8.26
> >>
> >> How can I come back into 1.10.8.24 ?
> >>
> >
> > cvs update -j 1.10.8.26 -j 1.10.8.25 snmp_core.cc
> > cvs update -j 1.10.8.25 -j 1.10.8.24 snmp
On ons, 2007-11-21 at 00:44 +0100, Rafael Martinez (Squid development)
wrote:
> > If snmp_core.cc revision 1.10.8.26
> >
> > How can I come back into 1.10.8.24 ?
> >
> >
>
> cvs update -j 1.10.8.26 -j 1.10.8.25 snmp_core.cc
> cvs update -j 1.10.8.25 -j 1.10.8.24 snmp_core.cc
yes, or in one g
Rafael Martinez (Squid development) wrote:
If snmp_core.cc revision 1.10.8.26
How can I come back into 1.10.8.24 ?
cvs update -j 1.10.8.26 -j 1.10.8.25 snmp_core.cc
cvs update -j 1.10.8.25 -j 1.10.8.24 snmp_core.cc
Is that the answer to your reversal question?
I'm a little unknowing in t
12 matches
Mail list logo
