SASGIS - SAS.Планета
View Issue Details
0002106SAS.Планета[All Projects] Багpublic21-08-2013 06:4607-02-2014 07:41
vdemidov 
zed 
normalminorhave not tried
resolvedfixed 
Windows7Enterprise 64
131111 
140303140303 
0002106: В процессе закачки видимой области выскакивают ошибки
При просмотре карты в режиме Кэш+Интернет на экране регулярно выскакивают ошибки декодирования тайлов.
На скриншоте ошибка декодирования png, но бывают похожие ошибки декодирования jpg.
Тип кэша проверялся родной файловый и неверсионный беркли - никакой разницы.
Инет медленный.
Комп очень быстрый Intel Core i7-3770 3.40GHz (8 потоков выполнения)

Ума не приложу в чем может быть проблема. Просто идей нет.
No tags attached.
related to 0002307resolved zed В процессе закачки видимой области "моргают" тайлы 
png fail.png (25,033) 21-08-2013 06:46
http://www.sasgis.org/mantis/file_download.php?file_id=1476&type=bug
png

zip SASPlanet.zip (2,854,006) 21-08-2013 08:01
http://www.sasgis.org/mantis/file_download.php?file_id=1477&type=bug
zip 1.zip (124,259) 21-08-2013 08:18
http://www.sasgis.org/mantis/file_download.php?file_id=1478&type=bug
zip SASPlanet.http.fix.zip (2,853,953) 22-08-2013 11:17
http://www.sasgis.org/mantis/file_download.php?file_id=1479&type=bug
Issue History
21-08-2013 06:46vdemidovNew Issue
21-08-2013 06:46vdemidovFile Added: fail.png
21-08-2013 06:56vdemidovStatusnew => confirmed
21-08-2013 07:14zedNote Added: 0012512
21-08-2013 07:27zedNote Added: 0012513
21-08-2013 07:29vdemidovNote Added: 0012514
21-08-2013 07:31vdemidovNote Added: 0012515
21-08-2013 07:31zedNote Added: 0012516
21-08-2013 07:33vdemidovNote Added: 0012517
21-08-2013 07:34zedNote Added: 0012519
21-08-2013 07:35vdemidovNote Added: 0012520
21-08-2013 07:37vdemidovNote Added: 0012522
21-08-2013 08:01zedFile Added: SASPlanet.zip
21-08-2013 08:02zedNote Added: 0012526
21-08-2013 08:18vdemidovFile Added: 1.zip
21-08-2013 08:18vdemidovNote Added: 0012527
21-08-2013 12:24vdemidovNote Added: 0012528
21-08-2013 12:43zedNote Added: 0012529
21-08-2013 12:51vdemidovNote Added: 0012530
21-08-2013 12:57zedNote Added: 0012531
21-08-2013 13:21vdemidovNote Added: 0012532
21-08-2013 13:48zedNote Added: 0012533
21-08-2013 13:52vdemidovNote Added: 0012534
21-08-2013 13:56vasketsovNote Added: 0012535
22-08-2013 06:42vdemidovNote Added: 0012538
22-08-2013 08:24vasketsovNote Added: 0012539
22-08-2013 08:27zedNote Added: 0012540
22-08-2013 08:29zedNote Added: 0012541
22-08-2013 08:29vdemidovNote Added: 0012542
22-08-2013 08:30vdemidovNote Added: 0012543
22-08-2013 08:35vasketsovNote Added: 0012544
22-08-2013 08:36vasketsovNote Edited: 0012544bug_revision_view_page.php?bugnote_id=12544#r5637
22-08-2013 08:46vdemidovNote Added: 0012546
22-08-2013 10:14vasketsovNote Added: 0012550
22-08-2013 10:37vdemidovNote Added: 0012551
22-08-2013 10:40vdemidovNote Added: 0012552
22-08-2013 10:45vasketsovNote Added: 0012553
22-08-2013 10:47vasketsovNote Edited: 0012553bug_revision_view_page.php?bugnote_id=12553#r5639
22-08-2013 10:48vdemidovNote Added: 0012554
22-08-2013 10:56zedNote Added: 0012555
22-08-2013 10:59zedNote Added: 0012556
22-08-2013 11:00vdemidovNote Added: 0012557
22-08-2013 11:15vdemidovNote Added: 0012558
22-08-2013 11:15vdemidovNote Edited: 0012558bug_revision_view_page.php?bugnote_id=12558#r5641
22-08-2013 11:17zedFile Added: SASPlanet.http.fix.zip
22-08-2013 11:18zedNote Added: 0012559
22-08-2013 11:20zedNote Added: 0012560
22-08-2013 11:33vdemidovNote Added: 0012561
22-08-2013 11:37vdemidovNote Added: 0012562
22-08-2013 11:42vasketsovNote Added: 0012563
22-08-2013 11:49zedNote Added: 0012564
22-08-2013 11:50zedNote Added: 0012565
22-08-2013 11:53vdemidovNote Added: 0012566
22-08-2013 11:59vasketsovNote Added: 0012567
23-08-2013 06:43vdemidovNote Added: 0012574
28-08-2013 10:06vdemidovNote Added: 0012641
28-08-2013 10:13vdemidovNote Added: 0012642
28-08-2013 10:43vasketsovNote Added: 0012643
28-08-2013 11:00vdemidovNote Added: 0012644
28-08-2013 13:37vasketsovNote Added: 0012656
28-08-2013 13:49vdemidovNote Added: 0012658
28-08-2013 14:13vasketsovNote Added: 0012660
28-08-2013 14:21vdemidovNote Added: 0012661
28-08-2013 15:01vasketsovNote Added: 0012662
28-08-2013 15:16vdemidovNote Added: 0012663
28-08-2013 15:45vasketsovNote Added: 0012664
22-11-2013 22:25vdemidovProduct Version.Nightly => 131111
07-01-2014 14:15zedRelationship addedrelated to 0002307
06-02-2014 21:35zedNote Added: 0013753
06-02-2014 21:36zedStatusconfirmed => feedback
07-02-2014 07:41vdemidovNote Added: 0013756
07-02-2014 07:41vdemidovStatusfeedback => new
07-02-2014 07:41vdemidovStatusnew => resolved
07-02-2014 07:41vdemidovResolutionopen => fixed
07-02-2014 07:41vdemidovAssigned To => zed
07-02-2014 07:41vdemidovFixed in Version => 140303
07-02-2014 07:41vdemidovTarget Version24xxxx => 140303

Notes
(0012512)
zed   
21-08-2013 07:14   
Скорее всего из интернета приходят битые/недокачанные данные. Может закачка по таймауту отваливается, а САС этого не замечает, но 99,9% дело в качалке.

Как конкретно ругается jpeg?
(0012513)
zed   
21-08-2013 07:27   
И можешь попробовать сохранить содержимое AData перед тем как оно бросает исключение чтобы посмотреть что оно там конкретно накачало и пытается открыть.
(0012514)
vdemidov   
21-08-2013 07:29   
> Скорее всего из интернета приходят битые/недокачанные данные.
Если бы все было так просто. Если бы сохранялся битый тайл он бы в кэше и оставался, а так при следующей перерисовке карты он отображается уже нормально и без ошибки.

>Как конкретно ругается jpeg?
Точно не помню, оно случается гораздо реже png, но общий смысл такой же, только ошибка от libjpeg
(0012515)
vdemidov   
21-08-2013 07:31   
> И можешь попробовать сохранить содержимое AData перед тем как оно бросает исключение чтобы посмотреть что оно там конкретно накачало и пытается открыть.
Увы не могу. На этом компе делфы нет и ставить нельзя под угрозой репрессий.
(0012516)
zed   
21-08-2013 07:31   
Но в режиме "Только из кэша" такого не наблюдается?
(0012517)
vdemidov   
21-08-2013 07:33   
>Но в режиме "Только из кэша" такого не наблюдается?
Нет, не наблюдается, но это не значит, что виновата именно качалка. Может это из-за ошибки при сохранении тайла.
(0012519)
zed   
21-08-2013 07:34   
>На этом компе делфы нет и ставить нельзя под угрозой репрессий.
Ну ты попал :) Скомпилить exe с сохранением AData при ошибке?
(0012520)
vdemidov   
21-08-2013 07:35   
Скомпиль, если не сильно сложно.
(0012522)
vdemidov   
21-08-2013 07:37   
>Ну ты попал :)
Ага. Причем это касается любого нелицензионного софта. Даже за Daemon Tools, поставившим его погрозили пальчиком и сказали так больше не делать :)
(0012526)
zed   
21-08-2013 08:02   
Будет сохранять проблемные тайлы в %TEMP% c префиксом "SAS" (в файлы вида SASXXXX.tmp)
(0012527)
vdemidov   
21-08-2013 08:18   
Как ни странно это действительно битые png.
(0012528)
vdemidov   
21-08-2013 12:24   
Воспроизвел ошибку на файловом тайлохранилище, а потом нашел файл похожий на тот что сохранился в темпе. В темпе записалось начало правильного тайла, но только половина. Похоже проблема в том, что в одном потоке мы сохраняем файл, причем ОС уже отрапортовала о завершении операции и мы разлочили синхронизатор, а в другом потоке при чтени мы получаем только начало файла, которое успело записаться. Смущает только то, что воспроизводится на БерклиДБ
(0012529)
zed   
21-08-2013 12:43   
>причем ОС уже отрапортовала о завершении операции и мы разлочили синхронизатор
Т.е. хочешь сказать, что оно в буфере винды и на диск ещё толком не записалось? Но для читающего потока винда же должна была отдать из буфера без проблем. А в Беркли к тому же, есть ещё и мем-кэш внутри САС, т.е. оно к диску/БД даже и не должно было обращаться (на чтение).
(0012530)
vdemidov   
21-08-2013 12:51   
Я завел этот инцидет, именно потому что не понимаю что происходит. Факт в том, что записало оно полный файл, а прочитало для отображения меньше половины этого файла. Что удивительно это происходит как с файлами так и берклиДБ. Где оно может портится?
(0012531)
zed   
21-08-2013 12:57   
Может сбоит ITileObjCacheBitmap?
(0012532)
vdemidov   
21-08-2013 13:21   
Нее, проблема еще до декодирования. А ITileObjCacheBitmap хранит уже раскодированные битмапки.
(0012533)
zed   
21-08-2013 13:48   
Перед сохранением в кэш ещё может сработать обрезка/ресайз, которая декодирует тайл. Т.е. у тебя может быть ситуация, что оно обломилось один раз с кропом и тайл таки НЕ сохранился в кэш, а потом пришёл следующий поток и успешно докачал и сохранил тайл. Вот и получилось, что и в кэше есть и ошибку ты увидел.
(0012534)
vdemidov   
21-08-2013 13:52   
Это могло бы быть так, но даже на скриншоте ошибка в Гибрид (Wikimapia) взятом из репозитория. А там никакой обрезки и ресайза при сохранении нет. Даже перекодирования из формата в другой формат быть не может, потому что ожидается только png (или текст, который считается эквивалентным png)
(0012535)
vasketsov   
21-08-2013 13:56   
>прочитало для отображения меньше половины этого файла
>а потом пришёл следующий поток и успешно докачал и сохранил тайл
Если запустить Filemon - это всё видно будет размеры буферов и порядок вызовов.
(0012538)
vdemidov   
22-08-2013 06:42   
Запустил ProcessMonitor. Все стало очень интересно.
Сначала прилетает
SetEndOfFileInformationFile EndOfFile: 5 440
Потом пара чтений
Потом опять
SetEndOfFileInformationFile EndOfFile: 8 416

Похоже дело таки в качалке тайлов.
Судя по всему дело в том, что в процессе закачки запросы на закачку тайла ставятся в очередь и отменяются. Но отмененный запрос, частично закачанный, почему-то сохраняется в базу, но потом сразу перетирается неотмененным запросом, но на быстром компе отображалка успевает подхватить тот битый тайл.
(0012539)
vasketsov   
22-08-2013 08:24   
А sacs тоже affected?
Я там переделывал сохранение тайла на диск для файловых хранилищ, чтобы в рамках одного открытия файла по хэндлу всё делать, а не через установку размера Stream.
(0012540)
zed   
22-08-2013 08:27   
А Беркли это значит каснулось из-за мем-кэша. В тайловый кэш по-моему так никто мем-кэш и не прикрутил?
(0012541)
zed   
22-08-2013 08:29   
>а не через установку размера Stream
А какая разница, если прилетает 2 отдельных запроса на запись?
(0012542)
vdemidov   
22-08-2013 08:29   
>А sacs тоже affected?
Не проверял, но подозреваю, что да.
> Я там переделывал сохранение тайла на диск для файловых хранилищ, чтобы в рамках одного открытия файла по хэндлу всё делать, а не через установку размера Stream.
Там ошибка на уровень выше. То есть, записали битый тайл, а потом переписали полным. Так что воспроизведется на всех типах тайлохранилищ.
(0012543)
vdemidov   
22-08-2013 08:30   
> А Беркли это значит каснулось из-за мем-кэша. В тайловый кэш по-моему так никто мем-кэш и не прикрутил?
Без разницы, что с мем-кэшом, что без. Проходят две операции записи в тайлохранилище. А между ними успевает пройти чтение.
(0012544)
vasketsov   
22-08-2013 08:35   
(edited on: 22-08-2013 08:36)
>Проходят две операции записи в тайлохранилище
>если прилетает 2 отдельных запроса на запись?
Это ты как понял? По ProcessMonitor-у? )))

(0012546)
vdemidov   
22-08-2013 08:46   
>Это ты как понял? По ProcessMonitor-у? )))
Ага. Плюс знание, что сейчас там есть блокировка на каждом тайлохранилище. Все операции сериализовались вполне нормально. Так что проблема в качалке.
(0012550)
vasketsov   
22-08-2013 10:14   
Но ты всё же проверь sacs.

>проблема в качалке
И в чём же она заключается-то в качалке?

>сразу перетирается неотмененным запросом
В том, что на один тайл непрокачанного экрана может быть 2 запроса на скачку? Так я об этом сто лет назад ещё писал.

>Но отмененный запрос
Почему запрос отменяется?
(0012551)
vdemidov   
22-08-2013 10:37   
>Но ты всё же проверь sacs.
Проверю

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

>Почему запрос отменяется?
Потому что карту подвинули и нас в первую очередь интересуют уже другие тайлы, чем интересовали раньше.
(0012552)
vdemidov   
22-08-2013 10:40   
>Но ты всё же проверь sacs.
Проверил. Все ровно то же самое, что и не удивительно.
(0012553)
vasketsov   
22-08-2013 10:45   
(edited on: 22-08-2013 10:47)
>сохраняет полученные данные, даже если запрос на закачку отменен
Результат (HTTP code) запроса какой будет (должен быть), если он отменён? 200 OK?

А какую-нибудь мегастарую версию пробовал запускать?

(0012554)
vdemidov   
22-08-2013 10:48   
>Результат (HTTP code) запроса какой будет (должен быть), если он отменён? 200 OK?
ХЗ. Я это в свое время делал для прямого использования WinInet. Потом Zed переделал на TALWinInetHTTPClient. Как оно сейчас работает, для меня почти загадка :)
(0012555)
zed   
22-08-2013 10:56   
При отмене запроса вызывается disconnect, и если у нас не возникает никакого исключения (не уверен, что alcinoe бросает в этом случае что-то) идёт вызов OnAfterResponse, в котором как раз и нету никакой проверки на то, что запрос отменён.
(0012556)
zed   
22-08-2013 10:59   
А Http code там будет 200, потому как вначале прилитают заголовки со статусом, а только потом тело. И если тело пришло не до конца, заголовки-то уже никто не будет исправлять. Конечно, если был разрыв связи на сокете, то мы словим исключение и уже не будем анализировать то что там успело накачаться.
(0012557)
vdemidov   
22-08-2013 11:00   
Ну вот похоже туда и нужно добавить проверку.
(0012558)
vdemidov   
22-08-2013 11:15   
Zed можешь перед строчками
        if Result = nil then begin
          Result := OnAfterResponse(
            ARequest,
            FResultFactory
          );
        end;
добавить проверку
        if ACancelNotifier.IsOperationCanceled(AOperationID) then begin
          Result := FResultFactory.BuildCanceled(ARequest);
        end;

и выложить где-то скомпиленную с этой проверкой версию?

(0012559)
zed   
22-08-2013 11:18   
Сделал так:

        if
          (Result = nil) and
          (not ACancelNotifier.IsOperationCanceled(AOperationID)) and
          (FDisconnectByServer = 0) and
          (FDisconnectByUser = 0)
        then begin
          Result := OnAfterResponse(
            ARequest,
            FResultFactory
          );
        end else begin
          Result := FResultFactory.BuildCanceled(ARequest);
        end;

Тестируй.
(0012560)
zed   
22-08-2013 11:20   
Меня там по коду в юните смущает доступ к переменным FDisconnectByServer и FDisconnectByUser без синхронизации. Это vasketsov добавлял, если что :)
(0012561)
vdemidov   
22-08-2013 11:33   
>Меня там по коду в юните смущает доступ к переменным FDisconnectByServer и FDisconnectByUser без синхронизации. Это vasketsov добавлял, если что :)
Понятия не имею. Я вообще не понял нафиг оно там нужно. В крайнем случае можно заменить флаг построенный на Interlocked*
(0012562)
vdemidov   
22-08-2013 11:37   
Что-то оно у меня вообще качать перестало
(0012563)
vasketsov   
22-08-2013 11:42   
>без синхронизации
ЕМНИП это Byte - а операции с Byte атомарны и без синхронизации

>не понял нафиг оно там нужно
ну очевидно это флаги отбоя по инициативе сервера или по инициативе пользователя

>vasketsov добавлял
значит известен тикет или хотя бы комментарии какие, почему такое сделано
(0012564)
zed   
22-08-2013 11:49   
> значит известен тикет

Changeset: 5096 (9bbf5ab98d53) 1103: обработка дисконнекта для TALWinInetHTTPClient
User: vasketsov
Date: 2012-02-25 19:59:58 +0400 (18 months)

Конечно, все ходы записаны :)
(0012565)
zed   
22-08-2013 11:50   
>Что-то оно у меня вообще качать перестало
У меня качает исправно.
(0012566)
vdemidov   
22-08-2013 11:53   
А у меня ни одного скачанного тайла
(0012567)
vasketsov   
22-08-2013 11:59   
>все ходы записаны
У меня даже больше инфы есть:
http://sasgis.org/mantis/view.php?id=1103#c5629
это про причину, читать от ссылки и далее.
(0012574)
vdemidov   
23-08-2013 06:43   
Я понял почему ошибки именно на слое гибрида викимапии у меня сыпятся - там сервер не отдает Content-Length в заголовке ответа. А у гугла отдает.
(0012641)
vdemidov   
28-08-2013 10:06   
Почитал код, вспомнил что там происходит. Я ошибся. Отмены начатого запроса на закачку тайла не происходит. Точнее происходит, но только если удаляется качальщик по таймауту или при закрытии программы. Так что судя по всему отлуп получаем на уровне сервера, а так как гибрид викимапии не возвращает Content-Length то и получаем недокачанные тайлы. Или я даже не знаю в чем проблема.

Вариантов два:
1. понять кто виноват, и что делать
2. не отправлять одновременно одинаковые запросы.

Второй вариант логичнее, но возникает вопрос как его реализовывать.
Кратко опишу как сейчас работает закачка тайлов:
1. Есть поток отвечающий за закачку видимой области конкретной карты. После каждого существенного сдвига карты пользователем старые запросы помечаются как отмененные, а в очередь запихивается новая пачка запросов.
2. Есть очередь запросов на закачку тайлов, в которую помещаются объекты-запросы содержащие зум, координаты тайла, версию. Очередь тупая FIFO, но у каждого запроса есть признак отменен ли он.
3. Есть определенное количество обработчиков очереди. Каждый обработчик забирает очередной запрос из очереди и начинает обрабатывать.
4. Если запрос уже отменен, то просто ничего не делаем, идем получать следующий запрос.
5. При помощи паскаль скрипта строим запрос на закачку включая хедеры + возможно в процессе выполняем какие-то HTTP запросы при помощи принадлежащего обработчику HTTP-загрузчику.
6. Если запрос отменен, то увы, выбрасываем построенный запрос и идем за следующей задачей.
7. Выполняем HTTP запрос при помощи все того же принадлежащего обработчику HTTP-загрузчику
8. Если мы выполнили HTTP запрос, то даже если запрос на тайл отменен, все равно сообщаем что скачали тайл и сохраняем его, если ошибки не было.

Итого вопрос. Куда и как пихать проверку дублирующихся HTTP запросов или как переделать всю эту кухню, что бы оно работало максимально эффективно.
(0012642)
vdemidov   
28-08-2013 10:13   
Возможно стоит добавить проверку наличия тайла непосредственно перед HTTP-запросом, если стоит режим Кэш+Интернет, или закачка идет в режиме без замены тайлов.
Но это никак не поможет от одновременных запросов одного и того же тайла, если один из обработчиков очереди уже начал HTTP запрос, который потом отменили и заменили новым, и другой обработчик начал его выполнять.
(0012643)
vasketsov   
28-08-2013 10:43   
>возникает вопрос как его реализовывать
Ну вариантов минимум два:

1. Дополнительный признак невозможности пользовательской отмены запроса. Соответственно подымать этот признак и не отменять запрос, если он уже прошёл какую-то стадию (в смысле http). Но при вырубании приложения вырубаются все. Возможно для чего-то другого тоже потребуется такое поведение (например, для операции, которую прерываем после тяжёлых промежуточных этапов, когда остался один простой лёгкий). Универсально и широкоиспользуемо в технике.

2. Внутренний список xyzv в том месте, одном на одну карту, в котором эти параметры ещё есть (возможно в httpdownloader они уже отсутствуют), там держать актуальный список, добавлять в начале закачки, выкидывать в конце закачки. По месту и тормоза.

Это если без сильных извратов.

>стоит добавить проверку наличия тайла непосредственно перед HTTP-запросом
Этого делать точно не стоит ввиду полной бессмысленности: если есть такой же параллельный поток на скачку, тайл ещё просто не упадёт.
Кроме того, какой тайл проверять, если скачанный мегатайл нарезается на кучку стандартных?
(0012644)
vdemidov   
28-08-2013 11:00   
1-й вариант совсем ничего не помогает, ибо оно и так не отменяется, а причин не добавлять новый запрос все так же нет. Точнее оно сейчас именно так и есть, и ты бы этого не писал, если бы внимательно прочитал то, что написал я.

2-й ваниант вызывает вопрос. И что делать если тайл уже есть в списке?

>>стоит добавить проверку наличия тайла непосредственно перед HTTP-запросом
>Этого делать точно не стоит ввиду полной бессмысленности: если есть такой же параллельный поток на скачку, тайл ещё просто не упадёт.
А если он уже упал, пока этот запрос в очереди стоял? Шансы очень даже большие.
(0012656)
vasketsov   
28-08-2013 13:37   
>ибо оно и так не отменяется
Отменяется - имел в виду подымается отметка об отмене, а не фактическую отмену.

>причин не добавлять новый запрос все так же нет
Наличие запроса в очереди - не причина?

>оно сейчас именно так и есть
Неправда. Сейчас отмена операции 146% взводит признак отмены операции, даже если операция фактически выполнилась. Попробуй подумать снова.

>2-й вариант вызывает вопрос. И что делать если тайл уже есть в списке?
Очевидно ничего, ибо можно дождаться первичного запроса, и не рожать вторичный.
(0012658)
vdemidov   
28-08-2013 13:49   
>Наличие запроса в очереди - не причина?
Я же написал, что очередь тупая, там нет метода проверки есть ли какой-то запрос в очереди или нет. Плюс сейчас отменяется все запросы скопом, если захочется делать поштучную отмену, то придется много чего переделывать.

>>оно сейчас именно так и есть
>Неправда. Сейчас отмена операции 146% взводит признак отмены операции, даже если операция фактически выполнилась. Попробуй подумать снова.
Сам подумай. Если начался http запрос то этот признак дальше уже игнорируется и больше не учитывается.

>>2-й вариант вызывает вопрос. И что делать если тайл уже есть в списке?
>Очевидно ничего, ибо можно дождаться первичного запроса, и не рожать вторичный.
В смысле не рожать вторичный? Проигнорировать вторичный. А рожать нужно. Или вводить методы изменения приоритета для запросов, что бы тайлы в нынешнем центре экрана загружались в первую очередь.
(0012660)
vasketsov   
28-08-2013 14:13   
>Если начался http запрос то этот признак дальше уже игнорируется и больше не учитывается
А как же проверка после окончания запроса, которая обсуждалась выше?
А кроме того, логично, что если запрос нельзя отменить, то ему нельзя и Disconnect руками сделать. Такое ощущение, что всё разжевать надо...

>очередь тупая, там нет метода проверки есть ли какой-то запрос в очереди или нет
У тебя же сейчас есть хэши - натяни проверку по хэшу xyzv.

>вводить методы изменения приоритета для запросов
Ты какую-то ересь несёшь. Ну при чём тут приоритеты, если не прокачаться может ЛЮБОЙ участок экрана?
(0012661)
vdemidov   
28-08-2013 14:21   
Так. Давай для начала ты внимательно посмотришь код, а потом будешь писать предположения как оно работает.
> А как же проверка после окончания запроса, которая обсуждалась выше?
Я сегодня с этого начал, что эта проверка срабатывает только при закрытии программы. Во всех остальных случаях, если запрос на закачку тайла добрался до Http он будет выполнен и его отмена игнорируется.

>>очередь тупая, там нет метода проверки есть ли какой-то запрос в очереди или нет
>У тебя же сейчас есть хэши - натяни проверку по хэшу xyzv
Для этого придется полностью переделывать очередь. Там сейчас только два метода Push и Pop.

>Ну при чём тут приоритеты, если не прокачаться может ЛЮБОЙ участок экрана?
Ничего не понял.
(0012662)
vasketsov   
28-08-2013 15:01   
>Ничего не понял
Это неудивительно. Попробуй завтра попробовать. Сегодня видимо не твой день.
Потому что в здравом уме такое написать нереально:
вводить методы изменения приоритета для запросов, что бы тайлы в нынешнем центре экрана загружались в первую очередь

>придется полностью переделывать очередь. Там сейчас только два метода Push и Pop
Почему Push внутри не может это сам проверять?

>Давай для начала ты внимательно посмотришь код
Давай.

>срабатывает только при закрытии программы
То есть TDownloaderHttp.OnCancelEvent (и Disconnect оттуда) при сдвиге карты не сработает? Зачем тогда FCancelListener цепляется к ACancelNotifier?
(0012663)
vdemidov   
28-08-2013 15:16   
>>Ничего не понял
>Это неудивительно. Попробуй завтра попробовать. Сегодня видимо не твой день.
Попробуй завтра написать другими словами. Сегодня ты несешь бред видимо не твой день. (Ты первый начал)

>>срабатывает только при закрытии программы
>То есть TDownloaderHttp.OnCancelEvent (и Disconnect оттуда) при сдвиге карты не сработает? Зачем тогда FCancelListener цепляется к ACancelNotifier?
Я третий раз пишу, что ACancelNotifier это совсем другой CancelNotifier чем тот что передается при создании запроса тайла, и он срабатывает только при удалении объекта обработчика очереди и при завершении работы программы.
(0012664)
vasketsov   
28-08-2013 15:45   
>первый начал
Неправда. Сообщения 12641 и 12642 уже содержат признаки тяжёлого повреждения ЦНС. Я лишь отвечаю на твой бред.

Например, для начала поясни, каким образом неотправка одинаковых запросов тебя спасёт? А если это будут одинаковые запросы от двух разных включённых слоёв, работающих по одному тайлохранилищу и по одному картосервису? Или отныне сас будет только строем ходить и в ногу?

Я не зря призываю тебя подумать ещё раз.
То что ты надумал сейчас - ересь 146%.
Поверь, что со стороны виднее.
Про приоритеты центра экрана - чистейший диагноз.
Такое ощущение, что или ты пьян, или аккаунт взломан, но это не vdemidov.

>Я третий раз пишу
Лучше ответь просто, "да" или "нет", вызывается Disconnect при сдвиге карты или нет?
(0013753)
zed   
06-02-2014 21:35   
В связи с доработкой 0002307 нужно подтверждение воспроизводимости бага в новом свете.
(0013756)
vdemidov   
07-02-2014 07:41   
Да, починилось. Я все еще считаю что качалку видимой области нужно переделать и избавиться от отдельного треда на каждую карту, но и так гораздо лучше чем было. Спасибо.