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. > > >
