Re: client_side and comm_close
Alex Rousskov wrote: On Fri, 2008-04-18 at 15:40 +1200, Amos Jeffries wrote: IMO, This should be queued as part of the 3.1 cleanups, but not as urgently as some other issues. The priorities as I see them now are: - immediately fixable and urgent bugs. - completing the dedicated 3.1 feature list (DEVEL is overdue). - cleanups for fixing more intrusive or design bugs (such as this, and the 407 one). - shakedown for release cycle. We have a few months of shakedown before anything like a good stable. Plenty of time for cleanup not blocking new features. I estimate that properly cleaning up the client side would delay v3.1 stable release by 2-3 months unless we suddenly get more experts involved. Is that delay acceptable to you? Others? If we were in a position to start it now, maybe. But we are not I think. I'm vote is for the timeline above, leaving step-3 as optional, the descision whether to even start it until step 2 is fully completed. We may later decide that it is worthwhile or vital, but I don't think anyone should start in on more major sweeping until we know what all the fallout from the currently underway set is going to be. Amos -- Please use Squid 2.6.STABLE19 or 3.0.STABLE4
Re: client_side and comm_close
On Wed, Apr 16, 2008, Alex Rousskov wrote: In short, we have several related problems here: (a) client_side code is incapable of reliably identifying whether comm_close has been called; (b) ConnStateData::isOpen may not work anymore; (c) client_side code uses many different ways to identify whether more data should be read from the connection; (d) comm_close is used a lot but no longer has an immediate effect and some client_side code may still depend on that effect to be immediate; (e) client_side comm handlers decent very deep, making it difficult to propagate errors and comm_close status up. We should decide whether to continue patching holes here and there or clean up the client_side*cc connection management mess for good. Should we continue to patch isolated v3.0 problems and cleanup v3.1? Or is this a v3.2 project? Or am I exaggerating the problems since common cases usually work fine? I'd suggest another option - roll back all of the async calls changes to the comm code, stabilise the codebase without it and re-evaluate what should occur (in smaller chunks, rather than dropping in a new comm manager) before reintroducing it. I think we've seen that there's still a gap in how development branches are tested and that the best way we have to test code is to put it in production :) Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: client_side and comm_close
On Fri, 2008-04-18 at 18:34 +1200, Amos Jeffries wrote: Alex Rousskov wrote: On Fri, 2008-04-18 at 15:40 +1200, Amos Jeffries wrote: IMO, This should be queued as part of the 3.1 cleanups, but not as urgently as some other issues. The priorities as I see them now are: - immediately fixable and urgent bugs. - completing the dedicated 3.1 feature list (DEVEL is overdue). - cleanups for fixing more intrusive or design bugs (such as this, and the 407 one). - shakedown for release cycle. We have a few months of shakedown before anything like a good stable. Plenty of time for cleanup not blocking new features. I estimate that properly cleaning up the client side would delay v3.1 stable release by 2-3 months unless we suddenly get more experts involved. Is that delay acceptable to you? Others? If we were in a position to start it now, maybe. But we are not I think. You are probably right. FWIW, I will not be able to work on that until eCAP is done. I'm vote is for the timeline above, leaving step-3 as optional, the descision whether to even start it until step 2 is fully completed. We may later decide that it is worthwhile or vital, but I don't think anyone should start in on more major sweeping until we know what all the fallout from the currently underway set is going to be. In the unlikely event somebody with enough client-side knowledge can start on this now, I would probably support it (and help with the design). Otherwise, I agree that your plan is the best option available. Thank you, Alex.
Re: client_side and comm_close
On Fri, 2008-04-18 at 16:15 +0800, Adrian Chadd wrote: On Wed, Apr 16, 2008, Alex Rousskov wrote: In short, we have several related problems here: (a) client_side code is incapable of reliably identifying whether comm_close has been called; (b) ConnStateData::isOpen may not work anymore; (c) client_side code uses many different ways to identify whether more data should be read from the connection; (d) comm_close is used a lot but no longer has an immediate effect and some client_side code may still depend on that effect to be immediate; (e) client_side comm handlers decent very deep, making it difficult to propagate errors and comm_close status up. We should decide whether to continue patching holes here and there or clean up the client_side*cc connection management mess for good. Should we continue to patch isolated v3.0 problems and cleanup v3.1? Or is this a v3.2 project? Or am I exaggerating the problems since common cases usually work fine? I'd suggest another option - roll back all of the async calls changes to the comm code, stabilise the codebase without it and re-evaluate what should occur (in smaller chunks, rather than dropping in a new comm manager) before reintroducing it. If the client_side's main problem was a few coding bugs caused by async call changes, you may have been right. Unfortunately, our main problem here is the client_side design flaws. Removing async calls from comm will not undo those flaws. The changes needed on the client-side are pretty much unrelated to async calls. Async calls just make the design problems more obvious and help in solving them. Removing async calls from comm will fix a few bugs, but will be a step backwards and will make ongoing code cleanup more difficult. Another way to look at it is to note that client_side was already pretty stable before async calls (i.e., Squid 3.0). Thus, we have already been where you are proposing to go. Alex.
ICAP - X-Client-IP header in respmod
Hello all, Using ICAP servers with Squid, I saw that Squid does not provide X-Client-IP header in respmod (header is present in reqmod). Not really a bug, but it makes it harder to follow HTTP request/response exchanges with an ICAP server. Is it linked to Squid or ICAP stack implementation, and is it possible to see this header provided in a future version ? Regards, Karel
Re: client_side and comm_close
On Fri, Apr 18, 2008, Alex Rousskov wrote: I'd suggest another option - roll back all of the async calls changes to the comm code, stabilise the codebase without it and re-evaluate what should occur (in smaller chunks, rather than dropping in a new comm manager) before reintroducing it. If the client_side's main problem was a few coding bugs caused by async call changes, you may have been right. Unfortunately, our main problem here is the client_side design flaws. Removing async calls from comm will not undo those flaws. I know this. The changes needed on the client-side are pretty much unrelated to async calls. Async calls just make the design problems more obvious and help in solving them. Removing async calls from comm will fix a few bugs, but will be a step backwards and will make ongoing code cleanup more difficult. But now you have a better understanding of the bugs that are introduced with AsyncCalls. You can then plan design changes to the client-side code to work around these. Another way to look at it is to note that client_side was already pretty stable before async calls (i.e., Squid 3.0). Thus, we have already been where you are proposing to go. Yes, then you left it by introducing something which exposed the bugs. Its great that we now know about the bugs - but now you've got a codebase that you're trying to stabilise and you can't guarantee you understand all of the possible ways its going to break in the future. If you back out the async related changes then you'll have a stable codebase again - you can then make smaller incremental changes to the codebase and test them to make sure you haven't broken anything, rather than spending possibly 6 + months finding more surprises. Remember, the initial idea was to use 3.1 to tidy up the codebase to stabilise it, not tidy up the codebase to unstabilise it. Redesigning chunks of the comm codebase -was- on my todo list for 3.1, but then people dumped stuff into 3 to make it less stable again. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
