Occasional Zero Sized Reply error with 2.6
Hi Henrik, I'm observing some occasional Zero Sized Reply error using 2.6 on native Windows. Reloading the page, it works fine. This is the access.log entry for the failing request 1151081760.062 0 172.30.128.1 TCP_MISS/502 1489 GET http://www1.it.squid-cache.org/Versions/v2/2.6/ acmeconsulting\guido.serassio DIRECT/81.174.20.197 text/html In cache.log was logged this: 2006/06/23 18:55:30| storeAufsOpenDone: (13) Permission denied 2006/06/23 18:55:30|g:/cache/squid/00/00/0001 2006/06/23 18:55:30| storeSwapOutFileClosed: dirno 0, swapfile 0001, errflag=-1 (13) Permission denied I'm using awin32, an aufs clone based on Windows native threads. What do you think about ? It could be a specific Windows problem ? Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
squid-3 vs 2.6
To follow up on some discussion seen on IRC. featurewise it's relatively small stuff in 2.6 not in squid-3 yet. Some of the things in 2.6 is more polished than in Squid-3 however, but these differences should even out as Squid-3 QA progresses. Missing features: - collapsed forwarding - WCCPv2 - TPROXY - Connection pinning for relaying of Microsoft Integrated Auth. - ETag - Follow X-Forwarded-For - anything else? Polishing: - Parts of the SSL cleanup. Main requirements being the pending bits in the comm code, or refactoring solving this I/O operation independence differently. - Reasonable read defer management. - COSS ng (or whatever to call what Adrian is doing to COSS). Some of this actually fits better in Squid-3 with it's re-factored I/O framework. - 2GB objects - HTCP updates - Many small bugfixes here and there in the new features common to both trees. - probably a bit more What happened to Squid-3 was that there was a release plan which was nice and cool about a quick translation to C++ but feature wise identical to 2.5. Then re-factoring was done a bit too far bringing a slew of stability issues combined with a lot of new features added (the two goes hand in hand, and was unavoidable at the time) resulting in a considerably higher divergence from Squid-2 than planned, and around this Robert (the main architect of the Squid-3 rewrite) got another job requiring a change in priorities on his part. As a result for a long time we had a Squid-3 tree which was in the mid of very many changes all over the place, and the architect behind these changes buzy elsewhere.. Also, some stuff was let into the tree a bit premature like the quite far going Range processing changes. With this situation there was not much choice but to continue developing in Squid-2 and forward porting the results to Squid-3 with the hope that the results will be useful the day Squid-3 shapes up.. I have a feeling we now finally have the tree Squid-3 in a quite consistent state, but a lot of bug fixing naturally remains. Most of the Squid-2 bugs remaining in port to Squid-3 status should however be taken mostly as hints there may be problems in these areas of Squid-3. In reality many of these likely doesn't exists in Squid-3, either from being fixed independently or re-factoring where the failing code has been rewritten eliminating the problem that way.. The majority of the expected Squid-3 bugs is likely unique to Squid-3, and not Squid-2 patches not yet forward ported.. To survive the main focus for Squid-3 MUST be to get the tree stable. Until we reach that point the community will continue to diverge as most customers still demands production ready deployment. I don't see it as a big problem if there is some features in Squid-2.6 which maybe will not be seen in Squid-3.0, that's why there is a Squid-3.1 release. The Squid-3 tree already have sufficient amount of new unique features to draw attention. Customers who are in need of any such 2.6 only feature will have the choice of running 2.6 and missing the new features only available in Squid-3, or make sure the feature they need is forward ported proper closing the gap from 2.6 to 3. The 2.6 release is actually about focusing the community again. It's better to have two focused releases, than the past situation of nearly every installation (including binary vendor distributions) unique with different combinations of patches applied to the feature-wise ancient 2.5 release. Myself have been running something which maybe resembles 70% of 2.6, and it's hard to find any larger installation running a stock 2.5 release. This has been very evident on the squid-users discussions in the last years which increasingly has been about applying different feature patches to 2.5, which is not a good sign for the health of the project. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Occasional Zero Sized Reply error with 2.6
fre 2006-06-23 klockan 19:14 +0200 skrev Guido Serassio: This is the access.log entry for the failing request 1151081760.062 0 172.30.128.1 TCP_MISS/502 1489 GET http://www1.it.squid-cache.org/Versions/v2/2.6/ acmeconsulting\guido.serassio DIRECT/81.174.20.197 text/html Is it reproducible? In cache.log was logged this: 2006/06/23 18:55:30| storeAufsOpenDone: (13) Permission denied 2006/06/23 18:55:30|g:/cache/squid/00/00/0001 2006/06/23 18:55:30| storeSwapOutFileClosed: dirno 0, swapfile 0001, errflag=-1 (13) Permission denied Hmm.. swapout failures have never been tested much. Would not be surprised if this cascades into more issues.. Why are you getting permission denied on create in your cache dir? Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 vs 2.6
Excellent email, thanks. On 24 Jun 2006, at 10:34, Henrik Nordstrom wrote: To follow up on some discussion seen on IRC. featurewise it's relatively small stuff in 2.6 not in squid-3 yet. Some of the things in 2.6 is more polished than in Squid-3 however, but these differences should even out as Squid-3 QA progresses. You say relatively small - but with the potential to cause lots of instability. Do you agree that most of these missing features would best be put in 3.1, after 3.0 has reached production stability? Perhaps the smaller and less risky ones might be acceptable into 3.0... but we must be very careful. Missing features: - collapsed forwarding - WCCPv2 - TPROXY - Connection pinning for relaying of Microsoft Integrated Auth. - ETag - Follow X-Forwarded-For - anything else? Polishing: - Parts of the SSL cleanup. Main requirements being the pending bits in the comm code, or refactoring solving this I/O operation independence differently. - Reasonable read defer management. - COSS ng (or whatever to call what Adrian is doing to COSS). Some of this actually fits better in Squid-3 with it's re-factored I/O framework. - 2GB objects - HTCP updates - Many small bugfixes here and there in the new features common to both trees. - probably a bit more Let's make sure all of these are in Bugzilla against 3.0, so we've got them quantified and in the public domain. What happened to Squid-3 was that there was a release plan which was nice and cool about a quick translation to C++ but feature wise identical to 2.5. Then re-factoring was done a bit too far bringing a slew of stability issues combined with a lot of new features added (the two goes hand in hand, and was unavoidable at the time) resulting in a considerably higher divergence from Squid-2 than planned, and around this Robert (the main architect of the Squid-3 rewrite) got another job requiring a change in priorities on his part. As a result for a long time we had a Squid-3 tree which was in the mid of very many changes all over the place, and the architect behind these changes buzy elsewhere.. Also, some stuff was let into the tree a bit premature like the quite far going Range processing changes. With this situation there was not much choice but to continue developing in Squid-2 and forward porting the results to Squid-3 with the hope that the results will be useful the day Squid-3 shapes up.. I have a feeling we now finally have the tree Squid-3 in a quite consistent state, but a lot of bug fixing naturally remains. Most of the Squid-2 bugs remaining in port to Squid-3 status should however be taken mostly as hints there may be problems in these areas of Squid-3. In reality many of these likely doesn't exists in Squid-3, either from being fixed independently or re-factoring where the failing code has been rewritten eliminating the problem that way.. The majority of the expected Squid-3 bugs is likely unique to Squid-3, and not Squid-2 patches not yet forward ported.. To survive the main focus for Squid-3 MUST be to get the tree stable. Until we reach that point the community will continue to diverge as most customers still demands production ready deployment. I don't see it as a big problem if there is some features in Squid-2.6 which maybe will not be seen in Squid-3.0, that's why there is a Squid-3.1 release. The Squid-3 tree already have sufficient amount of new unique features to draw attention. Customers who are in need of any such 2.6 only feature will have the choice of running 2.6 and missing the new features only available in Squid-3, or make sure the feature they need is forward ported proper closing the gap from 2.6 to 3. The 2.6 release is actually about focusing the community again. It's better to have two focused releases, than the past situation of nearly every installation (including binary vendor distributions) unique with different combinations of patches applied to the feature-wise ancient 2.5 release. Myself have been running something which maybe resembles 70% of 2.6, and it's hard to find any larger installation running a stock 2.5 release. This has been very evident on the squid-users discussions in the last years which increasingly has been about applying different feature patches to 2.5, which is not a good sign for the health of the project. Thanks - good to know the history. I repeat what I said before about having this kind of stuff on the website: we need an up to date News section + homepage coverage. Otherwise only about 6 people in the entire world know about it. What we're missing is an easy way to update the main web content, otherwise it won't get done... Can we port the entire website to the new Wiki? Regards Henrik Squid-2.6 has filled a gap and bought us some time - customers have extra features in a stable stock build. The next - and pressing - priority for the community must
Re: Occasional Zero Sized Reply error with 2.6
On Fri, Jun 23, 2006, Guido Serassio wrote: Hi Henrik, I'm observing some occasional Zero Sized Reply error using 2.6 on native Windows. Reloading the page, it works fine. I'm seeing it in my polygraph testing under 2.6 + COSS. It may be related. Adrian
Re: squid-3 vs 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doug Dixon wrote: Excellent email, thanks. On 24 Jun 2006, at 10:34, Henrik Nordstrom wrote: To follow up on some discussion seen on IRC. featurewise it's relatively small stuff in 2.6 not in squid-3 yet. Some of the things in 2.6 is more polished than in Squid-3 however, but these differences should even out as Squid-3 QA progresses. You say relatively small - but with the potential to cause lots of instability. Do you agree that most of these missing features would best be put in 3.1, after 3.0 has reached production stability? Perhaps the smaller and less risky ones might be acceptable into 3.0... but we must be very careful. Missing features: - collapsed forwarding - WCCPv2 - TPROXY - Connection pinning for relaying of Microsoft Integrated Auth. - ETag - Follow X-Forwarded-For - anything else? Polishing: - Parts of the SSL cleanup. Main requirements being the pending bits in the comm code, or refactoring solving this I/O operation independence differently. - Reasonable read defer management. - COSS ng (or whatever to call what Adrian is doing to COSS). Some of this actually fits better in Squid-3 with it's re-factored I/O framework. - 2GB objects - HTCP updates - Many small bugfixes here and there in the new features common to both trees. - probably a bit more Let's make sure all of these are in Bugzilla against 3.0, so we've got them quantified and in the public domain. What happened to Squid-3 was that there was a release plan which was nice and cool about a quick translation to C++ but feature wise identical to 2.5. Then re-factoring was done a bit too far bringing a slew of stability issues combined with a lot of new features added (the two goes hand in hand, and was unavoidable at the time) resulting in a considerably higher divergence from Squid-2 than planned, and around this Robert (the main architect of the Squid-3 rewrite) got another job requiring a change in priorities on his part. As a result for a long time we had a Squid-3 tree which was in the mid of very many changes all over the place, and the architect behind these changes buzy elsewhere.. Also, some stuff was let into the tree a bit premature like the quite far going Range processing changes. With this situation there was not much choice but to continue developing in Squid-2 and forward porting the results to Squid-3 with the hope that the results will be useful the day Squid-3 shapes up.. I have a feeling we now finally have the tree Squid-3 in a quite consistent state, but a lot of bug fixing naturally remains. Most of the Squid-2 bugs remaining in port to Squid-3 status should however be taken mostly as hints there may be problems in these areas of Squid-3. In reality many of these likely doesn't exists in Squid-3, either from being fixed independently or re-factoring where the failing code has been rewritten eliminating the problem that way.. The majority of the expected Squid-3 bugs is likely unique to Squid-3, and not Squid-2 patches not yet forward ported.. To survive the main focus for Squid-3 MUST be to get the tree stable. Until we reach that point the community will continue to diverge as most customers still demands production ready deployment. I don't see it as a big problem if there is some features in Squid-2.6 which maybe will not be seen in Squid-3.0, that's why there is a Squid-3.1 release. The Squid-3 tree already have sufficient amount of new unique features to draw attention. Customers who are in need of any such 2.6 only feature will have the choice of running 2.6 and missing the new features only available in Squid-3, or make sure the feature they need is forward ported proper closing the gap from 2.6 to 3. The 2.6 release is actually about focusing the community again. It's better to have two focused releases, than the past situation of nearly every installation (including binary vendor distributions) unique with different combinations of patches applied to the feature-wise ancient 2.5 release. Myself have been running something which maybe resembles 70% of 2.6, and it's hard to find any larger installation running a stock 2.5 release. This has been very evident on the squid-users discussions in the last years which increasingly has been about applying different feature patches to 2.5, which is not a good sign for the health of the project. Thanks - good to know the history. I repeat what I said before about having this kind of stuff on the website: we need an up to date News section + homepage coverage. Otherwise only about 6 people in the entire world know about it. What we're missing is an easy way to update the main web content, otherwise it won't get done... Can we port the entire website to the new Wiki? Regards Henrik Squid-2.6 has filled a gap and bought us some time - customers have extra
