[Qt-interest] Persistent HTTP connections

[Mandeep Sandhu]

On Thu, Feb 18, 2010 at 5:04 PM, Markus Goetz <Markus.Goetz at nokia.com> wrote:
> Yes, there will be a leak :)
>
> The deleteLater() refers to the object, e.g. to each individual
> QNetworkReply.

Ok.

Hey, I forgot to mention that I'm using Qt 4.5.3. So this might not be
an issue with the latest release (haven't tested it in 4.6).

Really sorry if I've sent you on a wild goose chase! :)

Should've mentioned this in the first mail.

Regards,
-mandeep


>
> ext Mandeep Sandhu wrote:
>>
>> On Thu, Feb 18, 2010 at 4:22 PM, Markus Goetz <Markus.Goetz at nokia.com>
>> wrote:
>>
>>>
>>> Oh.
>>> No, it is not your fault.
>>> It's a bug in Qt then. Calling deleteLater() is what you are supposed to
>>> do.
>>> I'll look into it.
>>>
>>
>> Oh ok. One more question.
>>
>> Will there be memory leak if i don't call deleteLater() for _every_
>> response, but call it only once when all downloads have finished?
>>
>> Thanks,
>> -mandeep
>>
>>
>>>
>>> Thanks for reporting.
>>>
>>> Markus
>>>
>>> ext Mandeep Sandhu wrote:
>>>
>>>>
>>>> Please ignore my previous mail.
>>>>
>>>> I found out why it was making a new connection each time. The
>>>> reason...my code! :P
>>>>
>>>> I was calling deleteLater() on the repy object which was causing it to
>>>> explicitly close the connection with the server.
>>>>
>>>> When I remove that, I see that the same connection is being reused for
>>>> subsequent requests.
>>>>
>>>> Thanks,
>>>> -mandeep
>>>>
>>>> On Thu, Feb 18, 2010 at 4:20 PM, Mandeep Sandhu
>>>> <mandeepsandhu.chd at gmail.com> wrote:
>>>>
>>>>
>>>>>
>>>>> On Thu, Feb 18, 2010 at 2:56 PM, Mandeep Sandhu
>>>>> <mandeepsandhu.chd at gmail.com> wrote:
>>>>>
>>>>>
>>>>>>>
>>>>>>> In theory, it should work like that. Have you tried checking with a
>>>>>>> network
>>>>>>> sniffer? If it's not like that, we have a bug (or let's call it
>>>>>>> performance
>>>>>>> regression) in Qt.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thats exactly what I'm trying now...using a sniffer.
>>>>>>
>>>>>>
>>>>>
>>>>> I tried using a singleshot timer to start the next download on
>>>>> receiving the "finished" signal (see attached source). I then used
>>>>> "NetActViewer" (http://netactview.sourceforge.net/) to view the active
>>>>> TCP connections to my box (where the webserver is running).
>>>>>
>>>>> I see that each time a new download starts, the client TCP port number
>>>>> is changing. This means that a new TCP connection is being made each
>>>>> time.
>>>>>
>>>>> I also sniffed one HTTP transaction off the wire...
>>>>>
>>>>> tshark shows the following for the HTTP request:
>>>>> ...
>>>>> ...
>>>>> Hypertext Transfer Protocol
>>>>>  GET /dl.txt HTTP/1.1\r\n
>>>>>      [Expert Info (Chat/Sequence): GET /dl.txt HTTP/1.1\r\n]
>>>>>          [Message: GET /dl.txt HTTP/1.1\r\n]
>>>>>          [Severity level: Chat]
>>>>>          [Group: Sequence]
>>>>>      Request Method: GET
>>>>>      Request URI: /dl.txt
>>>>>      Request Version: HTTP/1.1
>>>>>  User-Agent: QT 1.0\r\n
>>>>>  Connection: Keep-Alive\r\n
>>>>>  Accept-Encoding: gzip\r\n
>>>>>  Host: 192.168.2.2\r\n
>>>>>  \r\n
>>>>> ...
>>>>> ...
>>>>>
>>>>> HTTP response from server:
>>>>> ...
>>>>> ...
>>>>> Hypertext Transfer Protocol
>>>>>  HTTP/1.1 200 OK\r\n
>>>>>      [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
>>>>>          [Message: HTTP/1.1 200 OK\r\n]
>>>>>          [Severity level: Chat]
>>>>>          [Group: Sequence]
>>>>>      Request Version: HTTP/1.1
>>>>>      Response Code: 200
>>>>>  Server: nginx/0.7.62\r\n
>>>>>  Date: Thu, 18 Feb 2010 10:01:21 GMT\r\n
>>>>>  Content-Type: text/plain\r\n
>>>>>  Content-Length: 6\r\n
>>>>>      [Content length: 6]
>>>>>  Last-Modified: Thu, 18 Feb 2010 08:56:44 GMT\r\n
>>>>>  Connection: keep-alive\r\n
>>>>>  Accept-Ranges: bytes\r\n
>>>>>  \r\n
>>>>> ...
>>>>> ...
>>>>>
>>>>> So I guess it is using the correct header...but somehow a new
>>>>> connection is being made each time.
>>>>>
>>>>> -mandeep
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> To be very sure, I would suggest to not create and send the request
>>>>>>> from the
>>>>>>> finished() slot but one event loop spin after that. You can achieve
>>>>>>> this by
>>>>>>> using a single shot timer set to 0 msec and sending the request from
>>>>>>> the
>>>>>>> timer's slot.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks for this tip.
>>>>>>
>>>>>> Regards,
>>>>>> -mandeep
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Markus
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>
>