Russian Qt Forum

Qt 4.3.1 и 4.3.2 (и есть подозрения что и другие версии тоже)

Есть сервлет под TomCat-ом и есть клиент на Qt, использующий QHttp.
При передаче последовательно, около 10-15 запросов, в определённый момент QHttp начинает отправлять только заголовок HTTP, не отправляя собственно тела, а поскольку в заголовке указан Content-Lenght, то сервлет ожидает данных, которые не приходят и у сервлета случается SocketTimeoutException (сам сервлет не виноват, смотрел TcpTrace-ом, именно Qt-шный клиент отсылает запросы не отсылая тела).

Самое интересное что я подписался на все сигналы QHttp и поглядел на процесс отсылки такого неправильного запроса.

requestStarted ID=13
|  dataSendProgress total=357 done=229   (здесь total абсолютно правильный и QHttp начинает отправлять хедер)
|  dataSendProgress total=229 done=229   (а вот здесь почему-то изменился total и я совершенно не понимаю, почему!)
|  dataReadProgress total=228 done=228   (ответ от сервлета принимается абсолютно нормально)
requestFinished ID=13 error=false

Сталкивался ли кто-нибудь с такой проблемой?
По каким причинам может внезапно, в процессе отправки запроса смениться total?
Не подскажете-ли, в какой направлении копать (с выделением памяти всё нормально и  QByteArray & data, и QIODevice * to живы всё время выполнения запросами, некорректной работы с памятью нету, проверено Bound Checker-ом)...

Люди, откликнитесь! Неужели никто не встречался с такой проблемой?

отправляется один и тот же пакет или разные? "в определённый момент" - момент всегда одинаковый?

и вообще, приведи код - хоть повторить и проверить можно будет

Пакеты разные, но суть у них одна - заголовок POST и указан Content-Lenght, в теле - небольшой кусок XML, деревце из 10 узлов (для определённости будем считать что это SOAP вызов). Кстати, хорошая мысль, попробую проверить на одинаковых пакетах...

В том-то и дело что ошибка, так сказать, неповторяемая и моменты каждый раз разные, ибо QHttp неблокируемый и там всё живёт на ивентах, которые приходят когда им вздумается,  к тому же нагрузка на сетку непостоянна и запросы идут с разной скоростью.
Даже возникла мысль написать в службу поддержки троллей...

Лады, вечером постараюсь его укоротить до читаемого.

Кстати, никто не пытался QHttp проверять с Bound Checker-ом? У меня онпри закрытии сокета QHttp, по завершении запроса, выдаёт очень неприятные ошибки (прога в 2 строчки, чисто QT экзампл), я её тоже вечером приведу.

поищи про профилирование на этом форуме - периодически эта тема поднимается и так же периодически завершается примерно одинаково

по теме:
я юзаю соап (есс-но ПОСТ-ом и есс-но ХМЛ) - не сильно сложная надстройка над кухттп - ни разу таких проблем не замечал. так что, код будет весьма кстати
/*лучше выложи сразу компилируемый код тарболлом куда-нть в шары*/

Т-а-к, код временно откладывается, ибо не удалось на мини-тесте из 3х строчек получить ту же ошибку, что очень странно (возможно это потому что я сменил Bound Checker на более свежий). Буду думать дальше.

Про профилирование и отлов ликов прочитал, но ни одного вразумительного слова не нашел. Да, большинство пользуется Bound Checker - ом и на этом всё обсуждение ошибок и ликов заканчивается :-). Очень обидно что никто не предложил другого средства для винды, ибо на большом проекте баунд чекеру откровенно тяжело работать (тот же Code Guard из Borland-а работает на порядке быстрее).

Ну и глючность у него фирменная багландовская. ;-)

С этим не поспоришь. Code Guard у меня такие лики пропускал, что закачаешься. Но зато быстро работает и всё-таки процентов 80-90 багов ловит. А вот Bound Checker у меня только стартует минуту...

Сорри, даже забыл что задавал вопрос, а сейчас, после структуризации форума он как-то наверх вылез.
Проблема, разумеется, была решена и я в двух словах расскажу в чём она была.
- клиент делал огромное количество запросов к серверу
- сам результат запроса был крохотный и с его выдачей сервер справлялся моментально
- но обработка этого результата на клиенте занимала порядочно времени
- обработка эта происходила прямо в методе requestFinished...

собственно, в этом и проблема, пока отрабатывал по несколько секунд в очереди один результат запроса, остальные покорно ждали, а сервер через положенное количество секунд генерил  SocketTimeoutException.

проблема разрешилась выносом обработки запроса из requestFinished в отдельный поток

ай-ай-ай...прямо, как маленький :)

Самому стыдно. Наверное неделю тупил.