View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001727 | SAS.Планета | Баг / Bug | public | 07-12-2012 16:10 | 07-01-2013 12:41 |
| Reporter | vasketsov | Assigned To | vdemidov | ||
| Priority | normal | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | duplicate | ||
| Platform | Windows | OS | Vista | OS Version | Ultimate |
| Product Version | .Nightly | ||||
| Summary | 0001727: Какая-то непонятка с закачкой | ||||
| Description | Лог закачки по НЕПРОКАЧАННОЙ области, закачка одна, режим экрана только кэш: Обработка файла: bingsat\z18\x81808\y39311.jpg ... Данный файл уже имеется в кэше Обработка файла: bingsat\z18\x81808\y39312.jpg ... Downloading... Обработка файла: bingsat\z18\x81808\y39313.jpg ... Downloading... (Ok!) Обработка файла: bingsat\z18\x81808\y39314.jpg ... Downloading... (Ok!) Что стало с тайлом bingsat\z18\x81808\y39312.jpg? Обработка этой достаточно большой области завершена, тайл так и не долетел... в чём может быть проблема, что даже об ошибке не написалось (если она вообще была)? | ||||
| Tags | No tags attached. | ||||
|
|
Возможно связано с тем, что если (без указания MaxConnectToServerCount) натравить сас на многопоточный прокси-сервер типа Handycache, в его логе при перемещении мышкой в режиме кэш+интернет некоторые тайлы скачиваются два раза. Это уже давно и не зависит от типа кэша, на файловом отлично воспроизводится (включаем интернт+кэш и лог на прокси, прогружается экран нормально, потом смещаем экран так чтобы не полностью уйти из прогруженной области, но чтобы некоторые тайлы остались в области видимости, на 2-3-4 раз отлавливается), на СУБД это отчётливо видно, потому что возникают лишние нарушения первичного ключа при вставке. Что-то явно не то с раздачей заданий на скачку ((( Таких как правило 1-4 тайлика за один раз, для тестов лучше брать тайлы без exif типа бинга, у них размер меньше и одинаковые легко по размеру в логе даже глазами ищутся среди полста записей, они недалеко друг от друга будут )) |
|
|
По второму возможно что MemCache или его использование подгаживает. На прокачанной области на прокачанном зуме изредка бывает запрос к предыдущему зуму (а таблички такой нет, и его сразу видно по ошибке) просто при старте при первом показе окна. Значит ранее возврашается "нет тайла" для оригинального зума. Соответственно если откалючить кэш в памяти хранилища, то запроса к PreZ нет, но она и так довольно редкая, чтобы после нескольких экспериментов утверждать, что однозначно MemCache возвращает не то что надо. Похоже что с пропаданием тайла в стартовом посте это не связано. зы. Таки допёр, если сначала был запрос не WithData а пото WithData - второй раз сас работает как будто тайла нет, сделал сохранение в MemCache только WithData - беда из этого поста (второе предложение) пропала, так что предыдущие проблемы с ней не связаны. |
|
|
Так в чем проблема то? |
|
|
1. Обработка файла: bingsat\z18\x81808\y39312.jpg ... Downloading... Обработка файла: bingsat\z18\x81808\y39313.jpg ... Downloading... (Ok!) поток то ли подвис то ли вылетел - сказать сложно, но exception-ов не было. но это ерунда и возможно связано с 2, с паузами в качалке (в других тикетах) и т.п. 2. если (без указания MaxConnectToServerCount) натравить сас на многопоточный прокси-сервер типа Handycache, в его логе при перемещении мышкой в режиме кэш+интернет некоторые тайлы скачиваются два раза. более подробно - сообщение от 07-12-2012 20:19. вот это - уже не ерунда. |
|
|
>поток то ли подвис то ли вылетел - сказать сложно, но exception-ов не было. Не. Скорее всего какая-то ошибка в обработке или что-то в этом духе. Нужно смотреть обработку результатов закачки именно в этом юните. Если бы не пришел результат поток бы просто висел и ждал его. Закачка по области строго последовательная и следующий запрос не отправляется пока не обработан предыдущий. |
|
|
>Закачка по области строго последовательная и следующий запрос не отправляется Ага. Коли там никто не порылся и всё ещё один поток - значит это тогда точно фигня, если просто мессага не выплюнулась. В принципе можно и забить )) А второе напрягает. Версионные СУБД при update-ах создают новую копию записи, а старую удаляют, это сильно неприятнее чем просто файл лишний раз переписать на диске. |
|
|
А для того что бы второго не было, нужно проверять наличие тайла не только перед постановкой запроса в очередь, но и перед выполнением запроса извлеченного из очереди. Но ты же первый будешь бухтеть, что куча лишних обращений к диску. |
|
|
>постановкой запроса в очередь, но и перед выполнением запроса извлеченного из очереди Не-а. Перед тем как возникает "второе" - имеем полностью выкачанный экран, так что никаких очередей уже нет, всё устаканилось, в статусбаре тайлы не PENDятся. Постановка запросов в очередь выполняется после сдвигания экрана. Именно в этом случае (при наличии уже выкачанных тайлов в области экрана) и возникает 2 потока на тайл. То что в скобках - возможно важно: если сдвинуть далеко, и все тайлы нового экрана надо качать - у меня "второго" не было ни разу (хотя возможно это просто случайность). Другой-то закачки в экран нет. Всё что закачено после сдвига - так или иначе прошло в этот момент через очередь. Очередь, судя по счётчику тайлов в ней в статусбаре, формируется сразу полностью. Значит она банально формируется в этом случае некорректно, если эта сформированная очередь содержит 2 запроса на один тайл. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 07-12-2012 16:10 | vasketsov | New Issue | |
| 07-12-2012 18:19 | vasketsov | Note Added: 0010165 | |
| 07-12-2012 18:24 | vasketsov | Note Edited: 0010165 | |
| 07-12-2012 19:42 | vasketsov | Note Added: 0010166 | |
| 08-12-2012 08:11 | vasketsov | Note Edited: 0010166 | |
| 10-12-2012 06:36 | vdemidov | Note Added: 0010175 | |
| 10-12-2012 06:40 | vasketsov | Note Added: 0010176 | |
| 10-12-2012 06:46 | vdemidov | Note Added: 0010179 | |
| 10-12-2012 07:00 | vasketsov | Note Added: 0010183 | |
| 10-12-2012 17:55 | vdemidov | Note Added: 0010184 | |
| 10-12-2012 18:37 | vasketsov | Note Added: 0010185 | |
| 07-01-2013 12:41 | vdemidov | Relationship added | duplicate of 0001760 |
| 07-01-2013 12:41 | vdemidov | Status | new => resolved |
| 07-01-2013 12:41 | vdemidov | Resolution | open => duplicate |
| 07-01-2013 12:41 | vdemidov | Assigned To | => vdemidov |
| 07-01-2013 12:41 | vdemidov | Status | resolved => closed |
| 08-08-2025 13:22 | zed | Category | Баг => Баг / Bug |