[Interest] [solved] Re: advice on debugging a qnetworkaccessmanager/qnetworkreply issue

Mandeep Sandhu mandeepsandhu.chd at gmail.com
Thu Aug 9 07:05:01 CEST 2012


> Is there a clean manner for using the QNAMs finished(qnetworkreply*)
> signal and then determining whose reply it is and calling its handler?
> Everything I can think of seems sorta clunky and error prone; or is
> there a synchronous QNAM-like class? Having to reimplement the HTTP
> code in a qtcpsocket seems counter-productive and qhttp is apparently
> deprecated.

I prefer to use the QNetworkReply::finished() signal rather than QNAMs
finished(qnetworkreply*) signal. Though in both cases, you will have
to keep the QNR object returned by the get/post method around.

In case you use QNAMs signal, have the QNR object, that get/post
method returned in the object dispatching the request, handly so that
you can compare it with the object in the QNAM:finished() signal. If
it's not the QNR for your request, ignore it. Otherwise reading the
QNR will result in other slots (that might be invoked later) seeing no
data in it (which is probably what you saw in your case).

HTH,
-mandeep


>
> Best Regards,
>
> Justin N. Ferguson
>
> On Wed, Aug 8, 2012 at 6:30 PM, Justin Ferguson <jnferguson at gmail.com> wrote:
>> Hi,
>>
>> I'm running into an issue in an application that I so far cannot
>> totally adequately explain why its occurring; I'm not posting any code
>> in this email simply because I want to describe the issue and see if
>> there is anything obvious I am missing when trying to debug the issue
>> and then failing that I have no qualms posting the code.
>>
>> Essentially, I have a window which creates two objects that share a
>> qnetworkaccessmanager object that do two separate http requests. I
>> connect the finished() signals for the qnetworkreply to the objects
>> themselves and process the data and then call an init() function that
>> actually does the network requests. The complication I am running into
>> is that 'sometimes' (probably ~3 out of 5 runs) the second objects
>> call to qnetworkreply->readall() is returning an empty qbytearray,
>> whereas other times it works without a hitch. The next oddity is that
>> if I change the order so that the second object's init() is called
>> first, then it always works without a problem.
>>
>> I could just change the order and be done with it, but I suspect I've
>> got some issue that will just crop up later and well, it seems wrong
>> to fix my issue that way.
>>
>> I've verified that the request is sent and read from the same thread,
>> that there is no error in the reply and via a packet sniffer that the
>> data is actually arriving. More over, I am being mindful to
>> qnetworkreply->close() and qnetworkreply->deleteLater() the replies
>> (two instances of qnetworkreply that are instance variables for the
>> objects in question). The object instances are not going out of
>> scope/getting destructed; both are allocated on the heap and atm they
>> just leak because I never destroy them & I've verified that neither
>> destructor is being called in a debugger. The network access manager
>> is not going out of scope/getting destructed, etc. This code is
>> executing prior to the main event loop being executed if that matters
>> any.
>>
>> Has anyone run into this? I'm not sure what else to check, there seems
>> to be no real rationale but the behavior to me says its going to be a
>> race/state condition potentially in the qt library itself, but I
>> wanted to see if anyone had encountered this prior to grabbing a six
>> pack and walking through the assembly to determine what exactly is
>> occurring.
>>
>> As I said, I have no issue posting the code, I just wanted to pick
>> peoples brains first and look through my code with any suggestions
>> people might have before doing so.
>>
>> Best Regards,
>>
>> Justin N. Ferguson
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest



More information about the Interest mailing list