Re: client_side and comm_close

Hi all,
Alex Rousskov wrote:
> In reply to comment #8 for bug #2309
> comm_read assertion failed: "ccb->active == false"
> http://www.squid-cache.org/bugs/show_bug.cgi?id=2309
>
>> Note to the one looking into this bug: The assert happens if a
>> comm_read() is called while there already is a comm_read() pending.
>
> Yes.
>
>> I would suspect the half closed client check has been wrongly
>> adopted to call comm_read where it used commSetSelect periodically
>> before..
> d
> The above may be true, but there are other conditions causing the same
> assertion in my tests, with and without the pending comm_close patch
> from Christos.
>

As I can understand the problem does not exist only in squid3.0 or only
in squid3-trunk.

The main problem with the client_side code is that the comm_read done by
the ConnStateData class, the comm_writes by the ClientSocketContext
class and comm_close (and other comm operations ) by all. This makes
very difficult to manage the comm related problems in client_side code....

> 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?
>
> Thank you,
>
> Alex.
>
>
>
Received on Tue Apr 22 2008 - 14:35:41 MDT