Re: HTTP client disconnection vs ICAP disconnection

Hello,

Just trying to understand correctly..

>> Therefore:
>>
>> 1. The close handler that had been set in the HttpStateData
>> constructor (HttpStateData::httpStateConnClosed()) is not called
>> (because closeServer() removed it).
>
> Good.

I'm not very familiar with the architecture, but how is that a good
thing? I thought (from analyzing non-problematic cases and the souce
code) that the close handler was responsible for the closing cleanup.
Why is it removed and not executed?
The close handler for HttpStateData (httpStateConnClosed) indirectly
calls cleanAdaptation and others (via deleteThis() -> callEnd() ->
ServerStateData::swanSong() -> cleanAdaptation()). That takes care of
the ICAP socket among other things.

>
>> 2. -> AsyncJob::deleteThis("HttpStateData::httpStateConnClosed") is not
>> called.
>
> Ambiguous whether this is needed. IIRC at this point doneAll() supposedly
> should return true which would lead to (3) below.
>
> The server side seems very twisted and does not appear to implement the
> Jobs API at the leaf HttpStateData level, doing it at the generic
> ServerStateData level instead.

I thought it had to be called in order to trigger deletion / cleanup.

If doneAll() returns true, done() will return true and that will allow
the body of AsyncJob::callEnd() to run, but callEnd() itself is called
by deleteThis() in the chain of calls initiated by the (removed) close
handler. ServerStateData::swanSong() will not be called unless
callEnd() is called. Is it supposed to be call some other way?

>> 3. -> AsyncJob::callEnd() is not called.
>
> Bad.

See above.

>
>> 4. -> ServerStateData::swanSong() is not called.
>
> Very bad.
>

Again, I thought this was to be part of the chain of events initiated
by the close handler.

>> 5. -> *** cleanAdaptation() is not called.
>> 6. -> "delete this" in AsyncJob::callEnd() is not called.
>> 7. -> The ICAP socket is not closed.
>>
>> If the client is not cancelled, handleAdaptationCompleted() is
>> eventually called and calls cleanAdaptation() itself. No visible
>> problem.
>>
>> With other ICAP services where cancellation occurs while the socket to
>> the ICAP service is still active, squid detects that the client
>> connection has been closed (FD closed) and the correct chain of
>> notification/events leads to correct ICAP cleanup. No visible problem.

I see those scenarios clean up via the close handler (because they are
not closing via closeServer(). Why is it different in this case?

>>
>
> Two problems I can see that need checking and fixing if confirmed from
> that:
>
>  * whatever stream reader is present (here adaptation) needs a kick every
> time serverComplete() is called. In a way that informs it there will no
> more data coming but X bytes are now ready to be handled.

Is there something already in place that does this and should be
executed on serverComplete()?

>
>  * HttpStateData needs to be left in a self-shutdown state
>

Thanks a lot,

John Craws

>
>> I'd really appreciate your help with this.
>>
>> Thank you,
>>
>> John Craws
>>
>> ------------
>>
>> On Tue, Feb 1, 2011 at 1:59 PM, Tsantilas Christos
>> <chtsanti_at_users.sourceforge.net> wrote:
>>> Hi John,
>>>  I did some simple tests and I am not seeing this problem on trunk or
> on
>>> the
>>> latest squid-3.1 on bzr repository. The connection to the icap server
>>> always
>>> closed.
>>> Is it possible to be an icap server bug?
>>>
>>> The debug section for the squid ICAP client  is the 93. Try to enable
>>> debug
>>> to see if you can understand where the problem is:
>>>  debug_options ALL,1 93,9
>>>
>>>
>>> On 02/01/2011 07:58 PM, John Craws wrote:
>>>>
>>>> Hi,
>>>>
>>>> Thanks for your reply. However, I should have added that:
>>>>
>>>> 1. I do not see FDs reused if the request is aborted. I see them
>>>> reused if the request completes.
>>>> 2. This is the case even with 'icap_persistent_connections off'.
>>>>
>>>> Thanks,
>>>>
>>>> John Craws
>>>>
>>>> ----------------
>>>>
>>>> On 01/02/11 09:04, John Craws wrote:
>>>>
>>>>     Hello,
>>>>
>>>>     I am going through the source code of 3.1.9/3.1.10 trying to find
>>>> the
>>>>     cause of a problem I am seeing with a squid instance configured to
>>>> use
>>>>     an ICAP service.
>>>>
>>>>     The setup works fine, but if the client (wget) is disconnected
>>>> while
>>>>     the response is being transferred (CTRL-C while receiving
>>>> relatively
>>>>     large data), the ICAP socket is never disconnected. This leads to
> a
>>>>     situation where the ICAP service is perpetually timing out on a
>>>> read
>>>>     operation on that socket.
>>>>
>>>>     I have not seen this occur with other ICAP services.
>>>>
>>>>     I would definitely appreciate if someone with better knowledge of
>>>> this
>>>>     part of the code could help me pinpoint where the relationship
>>>> between
>>>>     those two is implemented.
>>>>
>>>> As I understand it ICAP should not be aware of the client and has an
>>>> independent set of persistent connections.
>>>>
>>>> The client disconnecting should set the ICAP output handlers to
>>>> discard the rest of the transaction and push the FD into an IdleFdList
>>>> waiting for another client request to use it.
>>>>
>>>> Alex or Christos know more about the finer details.
>>>>
>>>> Amos
>>>> --
>>>> Please be using
>>>>   Current Stable Squid 2.7.STABLE9 or 3.1.10
>>>>   Beta testers wanted for 3.2.0.4
>>>>
>>>
>>>
>
Received on Wed Feb 09 2011 - 20:05:18 MST