Anonymous | Login | Signup for a new account | 21-11-24 12:43 UTC |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002472 | SAS.Планета | [All Projects] Баг | public | 05-08-2014 10:06 | 13-08-2014 13:55 | ||||
Reporter | T_Im | ||||||||
Assigned To | zed | ||||||||
Priority | high | Severity | crash | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | Windows | OS | XP | OS Version | SP3 | ||||
Product Version | 140303 | ||||||||
Target Version | 141111 | Fixed in Version | 141111 | ||||||
Summary | 0002472: Часть тайлов в режиме кеш+интернет проскакивают мимо прокси | ||||||||
Description | Настроил свой прокси сервер на локалхосте (для гафической обработки тайлов), перемещаясь по карте часть тайлов _иногда_ начинают грузиться необработанными. | ||||||||
Steps To Reproduce | Для локализации глюка: в настройках SAS ставлю прокси Proxomitron - 127.0.0.1:8192, в проксомитроне включаю внешним прокси свой 127.0.0.1:5000 и включаю в проксомитроне Log Window. Шарюсь по карте в режиме кеш+интернет до первого прошедшего мимо прокси тайла (поскольку я делаю графическую коррекцию, то его видно визуально). Копирую адрес тайла на сервере, но в логе проксомитрона он отсутствует => это глюк SAS. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Notes | |
(0014468) zed (manager) 05-08-2014 10:13 |
А может он из кэша подтянулся? Вот если бы вы работали в режиме Интернет, то можно было бы говорить о каком-то глюке, хотя ещё не факт, что он на стороне SAS. |
(0014469) T_Im (reporter) 05-08-2014 10:18 |
Тайлы обычно начинают проскакивать не сразу. Возможно это как то зависит от интенсивности загрузки - как правило, это начинается если резко передвинуться на непрогруженное новое место. Если тайлы уже начали проскакивать мимо прокси, то дальше это приобретает систематический характер - проскакивать начинают большими пачками. Есть подозрение, что такое редко бывает и при скачивании по выделению. |
(0014470) T_Im (reporter) 05-08-2014 10:20 |
>А может он из кэша подтянулся? Нет, экспериментировал на нулевых кешах. Явление это не единичное. |
(0014471) T_Im (reporter) 05-08-2014 10:23 edited on: 05-08-2014 10:24 |
>Вот если бы вы работали в режиме Интернет, то можно было бы говорить о каком-то глюке, хотя ещё не факт, что он на стороне SAS. Если надо - могу выложить предварительно настроенную связку Proxomitron + Мой прокси + САС с единственной картой без кеша. Если пару минут пошариться - глюк обязательно вылезает. |
(0014472) zed (manager) 05-08-2014 10:31 |
1. Попробуйте вместо Proxomitron использовать HandyCache (там тоже можно включить ведение лога). Может это глючит именно Proxomitron - не пишет запрос в лог и не ходит на родительский прокси? 2. Попробуйте настройки прокси задавать в IE и указать SAS брать их оттуда. 3. Попробуйте ограничить количество потоков для карты до 1 или наоборот, увеличить до 12 (MaxConnectToServerCount в zmp). 4. Тестируйте на режиме Интернет. Интересно так же посмотреть на http заголовки глючных запросов. Они как-то отличаются от обычных? |
(0014473) T_Im (reporter) 05-08-2014 10:38 edited on: 05-08-2014 10:45 |
1. Пробовал привокси - не помогло 2. Тоже глючит. 3,4 - попробую. >Интересно так же посмотреть на http заголовки глючных запросов. Они как-то отличаются от обычных? Вот поэтому я и вставлял Proxomitron/Privoxy ДО своего прокси - но т.к. глючный запрос идет мимо прокси (вывод, основанный на отсутствии адреса глючного тайла в логе, но присутствии в логе адресов соседних с ним неглючных тайлов) - то не представляю, как его посмотреть. |
(0014474) zed (manager) 05-08-2014 10:47 |
> не представляю, как его посмотреть Снифером, когда они начинают идти пачками. IE Analyzer, WireShark. Да и со снифера и надо было начинать, а не ставить дополнительный прокси, чтобы не вносить лишнее звено, где оно может заглючить. И таки покажите свой прокси, на чём написан, под какие нагрузки рассчитан? Может это он отказывается обслуживать запросы? |
(0014475) T_Im (reporter) 05-08-2014 11:35 edited on: 05-08-2014 11:39 |
Proxy написан на Перле отсюда http://sasgis.org/forum/viewtopic.php?f=3&t=2206 >Может это он отказывается обслуживать запросы? Если я правильно понимаю, если выходят таймауты, САС должен пропустить тайл, а не качать в обход прокси. Вот лог HTTP Analyser (75.6 КБ, без тел ответов) http://rghost.ru/57292798 В начале идут неглючные запросы, потом, например: http://212.26.144.110/tile2/orto_10000/9/298/341.jpg http://212.26.144.110/tile2/orto_10000/9/302/340.jpg http://212.26.144.110/tile2/orto_10000/9/306/337.jpg идущие мимо прокси. |
(0014476) T_Im (reporter) 05-08-2014 11:43 edited on: 05-08-2014 11:44 |
Вот лог только двух запросов (заменял тайл по Ctr+Ins) - в первый раз заменило глючно в обход прокси, второй раз - нормально. http://rghost.ru/57293064 |
(0014477) zed (manager) 05-08-2014 11:59 edited on: 05-08-2014 12:00 |
> второй раз - нормально. Но ведь в логе, через прокси прошло 2 запроса. И они, кстати, очень сильно отличаются по передаваемым заголовкам. |
(0014478) T_Im (reporter) 05-08-2014 12:04 |
Когда начинают пачками приходить тайлы в обход прокси, в браузере настроенном на прокси, эти же тайлы открываются без глюков (если постоянно жать F5 - то в браузере тайл ни разу не перегружался глючным, в то время как в SAS этот же тайл по ctr+ins в 2-3-х случаях из 10 грузится глючным). |
(0014479) T_Im (reporter) 05-08-2014 12:09 |
>Но ведь в логе, через прокси прошло 2 запроса. И они, кстати, очень сильно отличаются по передаваемым заголовкам. Но, насколько я вижу, заголовки отличаются и у запросов на прокси САС-планеты, хотя должны быть практически идентичными. Прокси должен обрабатывать только тип image/jp*, но тут все вроде image/jpeg... |
(0014480) zed (manager) 05-08-2014 12:13 |
> Прокси должен обрабатывать только тип image/jp* Это каким образом у вас настроено? Может как раз таки у вас там ложное срабатывание (или несрабатывание) происходит? |
(0014481) T_Im (reporter) 05-08-2014 12:18 edited on: 05-08-2014 12:19 |
>Это каким образом у вас настроено? Может как раз таки у вас там ложное срабатывание (или несрабатывание) происходит? Проверял, там ошибок нет. >Но ведь в логе, через прокси прошло 2 запроса. Это ОДИН запрос от второго запроса САС. Две строчки в логе - это картинка на "входе-из-инета" и на "выходе-для-САС" (т.е. каждый запрос САС порождает в логе два запроса от прокси). Если этот xml открыть в текстовом виде - там видно, что первый запрос САС на прокси не идет. |
(0014482) T_Im (reporter) 05-08-2014 12:26 edited on: 05-08-2014 12:33 |
http://rghost.ru/57294114 Вот два запроса полностью с телами - один хороший, другой плохой - если зайти в Response Content - то видно какая картинка куда приходит. Плохой запрос идет в обход прокси. |
(0014483) zed (manager) 05-08-2014 12:36 |
Т.е. ваш прокси, получив запрос от SAS ходит вначале на сервер, а потом ещё куда-то? Почему тогда этого третьего нету в снифе? |
(0014484) T_Im (reporter) 05-08-2014 12:42 edited on: 05-08-2014 12:43 |
Нет. Ваша ошибка: "Но ведь в логе, через прокси прошло 2 запроса." Две строки в логе не значит два прошедших запроса. Откройте !good.xml и посмотрите Response Content каждой из трех строк. Две троки в логе от моего прокси - это картинка полученная из инета и картинка отданная САС-планете === один запрос прошедший через прокси. Сравните с !bad.xml где САС вообще не пытается связаться с прокси и шлет странные хедеры. |
(0014486) zed (manager) 05-08-2014 12:58 |
А Proxomitron выключен? |
(0014488) zed (manager) 05-08-2014 13:06 |
Судя по вашему первому логу, там первая сотня запросов вообще в интернет не выходила, а крутилась на localhost. |
(0014492) T_Im (reporter) 05-08-2014 18:35 edited on: 05-08-2014 18:52 |
Proxomitron выключен. >там первая сотня запросов вообще в интернет не выходила, а крутилась на localhost. Так ведь мой прокси localhost:5000. С него запрос идет дальше в интернет (собственно поэтому каждый правильный неглючный запрос - это 3 строчки лога). В том конкретном примере прокси удалял логотипы с тайлов. |
(0014493) zed (manager) 05-08-2014 19:55 |
Странный у вас какой-то прокси. У меня есть самописный GeoCacher, плюс иногда пользуюсь HandyCache и ни у одного из них я не наблюдаю сдвоенных запросов в снифере. Вы можете воспроизвести баг НЕ на своём прокси? Ну, т.е. исключить его вообще из цепочки? Возмите из аттача DebugView и SAS и понаблюдайте за дебажным выводом, там должны быть строчки типа "[3208] Set PROXY: 127.0.0.1:8080" и вариации. В тот момент, когда появляются эти строчки, SAS настраивает качалку (при первом запросе или изменении настроек) и если происходит сбой в настройках, в логе он должен засветиться. Какая у вас версия IE? Обновите до максимально возможной или до самой свежей, при возможности. |
(0014494) zed (manager) 05-08-2014 20:14 |
Чтобы протестировать глюк через HandyCache, в zmp нужно вписать несуществующий хост (выдумать), а в HC создать правило в Переадресации, которое будет заменять фейковый хост на реальный. Так вы сразу же получите в SAS ошибку, при попытке скачать мимо прокси. |
(0014495) T_Im (reporter) 06-08-2014 08:15 edited on: 06-08-2014 08:22 |
>Вы можете воспроизвести баг НЕ на своём прокси? ИМХО, этот баг возникает только при большой нагрузке на прокси, когда САС приходится долго ждать от него ответ (графическая обработка тайла весьма ресурсоемка), что, вероятно, и приводит к багу. Не представляю, как это можно воспроизвести простыми альтернативными способами. лог DebugView (сначала грузилось нормально, потом пошли глючные тайлы): 00000001 0.00000000 [2256] Set PROXY: 127.0.0.1:5000 00000002 32.90780640 [2256] Set PROXY: 127.0.0.1:5000 00000003 32.91172791 [2256] Set PROXY: 127.0.0.1:5000 00000004 32.91339111 [2256] Set PROXY: 127.0.0.1:5000 Debug info из САС http://rghost.ru/57313210 >Какая у вас версия IE? 6.0, обновлять нежелательно. >ни у одного из них я не наблюдаю сдвоенных запросов в снифере Посмотрите response content для каждой из трех строк в файле !good.xml (выкладывал в этом посте http://sasgis.org/mantis/view.php?id=2472#c14482). Если загрузить !good.xml в Http analyser, то в каждой из трех строк в табе "response content" можно увидеть соответствующую картинку. Видно, что реально запрошенная из интернета картинка - это запрос №3, поскольку только на этой картинке присутствует логотип. В запросах №1 и №2 на картинке логотипа нет - т.е. это уже прошедшие через прокси картинки (они НИКАК не могли прийти напрямую из интернета). Поэтому, предполагаю, строка №1 - это то, что отдает мой прокси на запрос в САС планету, а строка №2 - это то, что на свой запрос получает САС планета. Если загрузить !bad.xml - то там единственный запрос САС планеты, тайл приходит сразу с логотипом. Никаких обращений к прокси я там не вижу. На всякий случай: !bad.xml был записан так: дождавшись пачек глючных тайлов, очистил лог, кликнул ctr+ins по тайлу (пришел глючный тайл), сохранил лог. Теперь, если я буду повторно нажимать на этом тайле ctr+ins - то с вероятностью 20-40% может прийти глючный тайл. Если я при этом включу в Опере localhost:5000, загружу этот же тайл и буду жать F5 - то в браузере этот файл будет в 100% случаев приходить без логотипа. => Глюк не на прокси, а в САС панете. |
(0014496) zed (manager) 06-08-2014 09:43 |
>ИМХО, этот баг возникает только при большой нагрузке на прокси Поэтому я и просил проверить при однопоточном варианте запросов с MaxConnectToServer=1, что должно исключить "большую нагрузку". Ответа я так пока и не дождался. > лог DebugView Лог в норме => SAS не глючит и настройки прокси не сбрасывает. >>Какая у вас версия IE? >6.0, обновлять нежелательно. Проверьте тогда на другом компе, где стоит более новая версия IE. У вас очень древний монстр, а SAS качает через него и может запросто глючить системная библиотека. >Поэтому, предполагаю, строка №1 - это то, что отдает мой прокси на запрос в САС планету, а строка №2 - это то, что на свой запрос получает САС планета. Это что-то невероятное :) В снифере отображаются соединения между двумя точками, поэтому то, что отдаёт сервер и то, что получает клиент это одно и то же и это выводится в одну строку. Поэтому тут либо снифер тупит, либо вы что-то недоговариваете и прокси работает не так, как вы описываете. Можете ещё с WireShark поэкспериментировать, уж он-то врать не станет. >Если я при этом включу в Опере Надо проверять в IE, остальные браузеры идут лесом. >то в браузере этот файл будет в 100% случаев приходить без логотипа Даже если одновременно с этим, нагрузить ваш прокси в 10 потоков со стороны SAS? Вы уж если экспериментируете с браузером, так под реальной нагрузкой смотрите, а не на холостом ходу ;) |
(0014497) T_Im (reporter) 06-08-2014 12:54 edited on: 06-08-2014 13:15 |
>MaxConnectToServer=1 Не помогает (прописал в zmp MaxConnectToServerCount=1). Внешне без видимых изменений. >Надо проверять в IE Проверил - то же, что и в Опере: САС глючит, F5 в IE каждый раз перегружает тайл без глюков. >что должно исключить "большую нагрузку" Что происходит: если быстро двигаться начинает расти счетчик SAS "осталось" до 20+ - 30+ тайлов (в это же время IE через тот же прокси грузит тайлы нормально!). Визуально загрузка тайлов в САС прекращается, потом, через некоторое время, счетчик "осталось" постепенно обнуляется (остаются белые квадраты, на их месте никаких сообщений об ошибках не пишется). Если переместиться - то тайлы снова начинают грузиться, но если быстро перемещаться - снова забивается очередь. Как правило после пары раз забивания очереди начинают грузится глючные тайлы с логотипами (браузер в это время нормально грузит снимок через прокси). >В снифере отображаются соединения между двумя точками, поэтому то, что отдаёт сервер и то, что получает клиент это одно и то же и это выводится в одну строку. >прокси работает не так, как вы описываете Прокси работает на этом стандартном модуле http://search.cpan.org/~book/HTTP-Proxy-0.301/lib/HTTP/Proxy/BodyFilter/complete.pm !tile_proxy.pl в архиве с комментариями (там все просто). ИМХО, второй "лишний" запрос прокси-сервера (ответом на который приходит уже обработанная картинка) - это внутренняя кухня перлового HTTP::Proxy::BodyFilter. Что там у него под капотом, по идее должно быть все равно, поскольку в логах я ни разу не видел, чтобы от прокси в САС уходила глючная картинка. >Лог в норме => SAS не глючит и настройки прокси не сбрасывает. Тогда почему при этом, если включить Analyzer, то в его логе идут запросы типа сохраненного !bad.xml? Вы согласны, что в таких запросах задокументировано ОТСУТСТВИЕ соединения САС-прокси? Как такое вообще может быть, если в настройках САС стоит 127.0.0.1:5000? Еще раз подчеркну: ни Proxomitron, ни Analyzer не видят, чтобы SAS соединялась с проксей при глючном запросе. В Ие и Опере при передвижении по карте на самом сайте при включенном проксе и одновременно глючащем САС ни один тайл не пришел глючным и загрузка тайлов ни разу не подвисала! Вот (2Мб) http://rghost.ru/57318715 мой прокси (!tile_proxy.exe) + папка SAS с единственным zmp (в нем прописано MaxConnectToServerCount=1) и SASPlanet.ini заруленный на прокси. Достаточно скинуть в папку САС и немного интенсивно походить по карте. Как полезут синие логотипы по центру тайла - значит, начались глюки. |
(0014498) zed (manager) 06-08-2014 18:53 edited on: 06-08-2014 19:00 |
> Достаточно скинуть в папку САС и немного интенсивно походить по карте Я смогу посмотреть на раньше воскресенья. И у меня нету IE6, поэтому может и не воспроизвестись. Upd: Попробовал просто запустить ваш прокси - выдаёт ошибку об отсутствии либы CORE_RL_magick_.dll. |
(0014499) T_Im (reporter) 06-08-2014 21:07 |
>выдаёт ошибку об отсутствии либы CORE_RL_magick_.dll. Необходимы библиотеки ImageMagick http://rghost.ru/57330920 (2МБ) |
(0014500) T_Im (reporter) 07-08-2014 07:56 edited on: 07-08-2014 07:57 |
Добрался до компа с почти голой семеркой+ИЕ8. Распаковался выложенным комплектом+библиотеками - все запустилось. Сас планета при запуске почти сразу забивает очередь загрузки (в графе осталось = 32 тайла) - и эти тайлы не грузит (остаются белые квадраты, счетчик со временем падает). При передвижениях очередь загрузки почти сразу забивается (там разрешение монитора большое) - после пары таких передвижений-затыков начинаются запросы в обход прокси - вылазит логотип. Параллельно, запускаю заруленный на прокси ИЕ8, открываю в нем Веб-источник карты http://212.26.144.110/kadastrova-karta (там переключиться в слоях "Шарах" на "ортофотопланы") - все тайлы при перемещениях грузятся без логотипов, небыстро, но без подвисаний и затыков (у сас очередь загрузки в это же время забита до отказа или же идут глючные тайлы с логотипами). Поставить на той машине свой софт не имею возможности, но, вероятно, дальше ковырять нужно уже исходники САС - ИМХО, там происходит где то затык при большом времени ответа сервера (большое время между GET-запросом от САС и ответом от прокси-сервера, поскольку обработка картинки идет довольно долго)+ возможно с этим как то связанный глюк хедеров, ведущий к отключению от прокси. |
(0014514) zed (manager) 11-08-2014 13:19 |
Да, творится какое-то непотребство. Проксик работает достаточно быстро, единственное, что не поддерживает Keep-Alive из-за чего происходят постоянные дисконнекты. Но временами в StatusCallback от wininet прилитает нечто несуразное, вместо ip проксика (127.0.0.1): > INTERNET_STATUS_RESOLVING_NAME - Looking up the IP address of the name: 16_38344_22613 > INTERNET_STATUS_RESOLVING_NAME - Looking up the IP address of the name: ttilematrixelement > INTERNET_STATUS_RESOLVING_NAME - Looking up the IP address of the name: tnearestresampler что говорит о том, что там где-то бьётся память. И напоровшись несколько раз на такие имена, оно может вдруг начать качать напрямую. А может и не начать, а продолжать ходить через прокси. Очень странная ситуация. И это в однопоточном тесте! T_Im вам пока могу посоветовать переписать прокси, чтобы он не рвал соединения. Или попробуйте поставить между ним и SAS HandyCache, который будет поддерживать соединение с SAS, даже если ваш прокси будет рвать коннект. |
(0014516) T_Im (reporter) 12-08-2014 10:35 edited on: 12-08-2014 10:54 |
>Или попробуйте поставить между ним и SAS HandyCache, который будет поддерживать соединение с SAS, даже если ваш прокси будет рвать коннект. Поставил HandyCache, то же самое - после пары затыков начинаются глюки. Аналогично, как я раньше писал, показывали Proxomitron/Privoxy: запрос со стороны САС идет мимо первого прокси, в независимости, мой это прокси или нет. >вам пока могу посоветовать переписать прокси, чтобы он не рвал соединения Разрыв соединений спрятан там где то глубоко во внутренностях модуля, чтобы его не было, вероятно надо все переписать с нуля на сокетах, в чем я практически не разбираюсь. Более того, есть вполне обоснованные подозрения, что не в разрывах дело - ведь в IE при этом ни разу не возникало таких глюков. Ответы tnearestresampler и ttilematrixelement похожи на какой то мусор от САС. При перезапуске САС глюк на время уходит. Тут скорее надо разбираться, в каком месте в самой САС возникает затык-переполнение очереди (в ИЕ таких затыков ни разу не наблюдалось), и как после этого формируются GET-запросы. |
(0014517) T_Im (reporter) 12-08-2014 10:49 |
Еще как вариант причины глюка: видно что в логах снифера присутсвуют строки как http 1.0 так и http 1.1. Может, в САС где то глюк с парсингом ответов Http 1.0? (например, где то неправильно инициализируется при парсинге переменная) |
(0014518) zed (manager) 12-08-2014 11:48 edited on: 12-08-2014 11:58 |
Проверьте приаттаченный exe. Upd: А нет, и он не работает. Добился гарантированного воспроизведения при MaxConnectToServerCount=16 - сразу же при запуске, один из потоков обязательно напарывается на ошибку и начинает ходить мимо прокси. |
(0014519) T_Im (reporter) 12-08-2014 12:01 edited on: 12-08-2014 12:05 |
Переписал прокси, используя стандартный пример на HTTP::Daemon и HTTP::Response - там было легко добавить Keep-Alive. При использовании Keep-Alive, тайлы стали грузиться заметно быстрее! Затык стал происходить заметно реже, но все равно случается, обычно если перемещаться на краях, где приходят нулевые тайлы - в 1 из 3-6-ти случаев затык ведет к появлению глюка. Есть большое подозрение, что глюк происходит из-за использования САС http 1.0 вместо 1,1. |
(0014520) zed (manager) 12-08-2014 12:02 |
> в каком месте в самой САС возникает затык-переполнение очереди Нету там затыков и переполнений. Там включается пауза в 30 с. после сбойного запроса. Можете в SASPlanet.ini параметру SleepOnResetConnection присвоить 1000 и затыки пройдут, но на баг это никак не повлияет. |
(0014521) zed (manager) 12-08-2014 12:07 |
> из-за использования САС http 1.0 Включите в настройках IE, чтобы он через прокси пускал http 1.1 и тестируйте. Если в настройках включено, а оно всё-равно ходит по 1.0, то обновите систему: http://support.microsoft.com/kb/947513/en |
(0014522) zed (manager) 12-08-2014 12:45 |
Приложил ещё один вариант. Потестируйте его в связке с DebugVeiw. |
(0014523) T_Im (reporter) 12-08-2014 15:03 |
Больше баг не вылазит. Тестировал как на старом, так и на новом проксях - везде качает без затыков и багов, помимо этого оттестировал с аналогичным результатом при 4-х соединениях с сервером в настройке zmp. |
(0014524) zed (manager) 12-08-2014 15:08 |
Отлично. Выходит, что баг был (и пока остаётся) в используемом компоненте, а не в самом SAS. Нужно думать, как его лучше исправить. |
(0014525) vdemidov (manager) 12-08-2014 15:12 |
Что там думать? Свои патчи для alcinoe мы и так держим в своем клоне. Одним больше, одним меньше - какая разница :) |
(0014527) T_Im (reporter) 12-08-2014 16:05 |
Вложенным файлом пока пользоваться можно безпроблемно? Правильно понимаю, что из изменений там только костыль на днс-запрос локалхоста сделан? |
(0014528) zed (manager) 12-08-2014 16:09 |
Пользоваться можно только через прокси на локалхосте, на другой прокси или напрямую просто не пустит. Сегодня же, надеюсь, будет правильная ночнушка. |
(0014529) zed (manager) 12-08-2014 18:28 |
Залил ночнушку, тестируйте в усиленном режиме. |
(0014534) T_Im (reporter) 13-08-2014 13:27 edited on: 13-08-2014 13:27 |
После прокачки нескольких десятков тысяч тайлов и активного передвижения по карте ни одного глюка не наблюдалось. |
Issue History | |||
Date Modified | Username | Field | Change |
05-08-2014 10:06 | T_Im | New Issue | |
05-08-2014 10:13 | zed | Note Added: 0014468 | |
05-08-2014 10:18 | T_Im | Note Added: 0014469 | |
05-08-2014 10:20 | T_Im | Note Added: 0014470 | |
05-08-2014 10:23 | T_Im | Note Added: 0014471 | |
05-08-2014 10:24 | T_Im | Note Edited: 0014471 | View Revisions |
05-08-2014 10:31 | zed | Note Added: 0014472 | |
05-08-2014 10:38 | T_Im | Note Added: 0014473 | |
05-08-2014 10:44 | T_Im | Note Edited: 0014473 | View Revisions |
05-08-2014 10:45 | T_Im | Note Edited: 0014473 | View Revisions |
05-08-2014 10:47 | zed | Note Added: 0014474 | |
05-08-2014 11:35 | T_Im | Note Added: 0014475 | |
05-08-2014 11:39 | T_Im | Note Edited: 0014475 | View Revisions |
05-08-2014 11:43 | T_Im | Note Added: 0014476 | |
05-08-2014 11:44 | T_Im | Note Edited: 0014476 | View Revisions |
05-08-2014 11:59 | zed | Note Added: 0014477 | |
05-08-2014 12:00 | zed | Note Edited: 0014477 | View Revisions |
05-08-2014 12:04 | T_Im | Note Added: 0014478 | |
05-08-2014 12:09 | T_Im | Note Added: 0014479 | |
05-08-2014 12:13 | zed | Note Added: 0014480 | |
05-08-2014 12:18 | T_Im | Note Added: 0014481 | |
05-08-2014 12:19 | T_Im | Note Edited: 0014481 | View Revisions |
05-08-2014 12:26 | T_Im | Note Added: 0014482 | |
05-08-2014 12:27 | T_Im | Note Edited: 0014482 | View Revisions |
05-08-2014 12:33 | T_Im | Note Edited: 0014482 | View Revisions |
05-08-2014 12:36 | zed | Note Added: 0014483 | |
05-08-2014 12:42 | T_Im | Note Added: 0014484 | |
05-08-2014 12:43 | T_Im | Note Edited: 0014484 | View Revisions |
05-08-2014 12:58 | zed | Note Added: 0014486 | |
05-08-2014 13:06 | zed | Note Added: 0014488 | |
05-08-2014 18:35 | T_Im | Note Added: 0014492 | |
05-08-2014 18:40 | T_Im | Note Edited: 0014492 | View Revisions |
05-08-2014 18:52 | T_Im | Note Edited: 0014492 | View Revisions |
05-08-2014 19:43 | zed | File Added: SAS.DebugProxy.7z | |
05-08-2014 19:55 | zed | Note Added: 0014493 | |
05-08-2014 20:14 | zed | Note Added: 0014494 | |
06-08-2014 08:15 | T_Im | Note Added: 0014495 | |
06-08-2014 08:21 | T_Im | Note Edited: 0014495 | View Revisions |
06-08-2014 08:22 | T_Im | Note Edited: 0014495 | View Revisions |
06-08-2014 09:43 | zed | Note Added: 0014496 | |
06-08-2014 12:54 | T_Im | Note Added: 0014497 | |
06-08-2014 13:12 | T_Im | Note Edited: 0014497 | View Revisions |
06-08-2014 13:15 | T_Im | Note Edited: 0014497 | View Revisions |
06-08-2014 18:53 | zed | Note Added: 0014498 | |
06-08-2014 19:00 | zed | Note Edited: 0014498 | View Revisions |
06-08-2014 21:07 | T_Im | Note Added: 0014499 | |
07-08-2014 07:56 | T_Im | Note Added: 0014500 | |
07-08-2014 07:57 | T_Im | Note Edited: 0014500 | View Revisions |
11-08-2014 13:05 | zed | File Deleted: SAS.DebugProxy.7z | |
11-08-2014 13:19 | zed | Note Added: 0014514 | |
12-08-2014 10:35 | T_Im | Note Added: 0014516 | |
12-08-2014 10:36 | T_Im | Note Edited: 0014516 | View Revisions |
12-08-2014 10:49 | T_Im | Note Added: 0014517 | |
12-08-2014 10:54 | T_Im | Note Edited: 0014516 | View Revisions |
12-08-2014 11:39 | zed | File Added: SASPlanet.DisabledCallBack.7z | |
12-08-2014 11:48 | zed | Note Added: 0014518 | |
12-08-2014 11:57 | zed | File Deleted: SASPlanet.DisabledCallBack.7z | |
12-08-2014 11:58 | zed | Note Edited: 0014518 | View Revisions |
12-08-2014 12:01 | T_Im | Note Added: 0014519 | |
12-08-2014 12:02 | zed | Note Added: 0014520 | |
12-08-2014 12:05 | T_Im | Note Edited: 0014519 | View Revisions |
12-08-2014 12:07 | zed | Note Added: 0014521 | |
12-08-2014 12:41 | zed | File Added: SASPlanet.PtrFix.7z | |
12-08-2014 12:45 | zed | Note Added: 0014522 | |
12-08-2014 15:02 | vdemidov | Assigned To | => zed |
12-08-2014 15:02 | vdemidov | Status | new => assigned |
12-08-2014 15:02 | vdemidov | Product Version | .Nightly => 140303 |
12-08-2014 15:02 | vdemidov | Status | assigned => feedback |
12-08-2014 15:03 | T_Im | Note Added: 0014523 | |
12-08-2014 15:03 | T_Im | Status | feedback => assigned |
12-08-2014 15:08 | zed | Note Added: 0014524 | |
12-08-2014 15:12 | vdemidov | Note Added: 0014525 | |
12-08-2014 16:05 | T_Im | Note Added: 0014527 | |
12-08-2014 16:09 | zed | Note Added: 0014528 | |
12-08-2014 18:28 | zed | File Deleted: SASPlanet.PtrFix.7z | |
12-08-2014 18:28 | zed | Note Added: 0014529 | |
13-08-2014 06:50 | vdemidov | Status | assigned => feedback |
13-08-2014 13:27 | T_Im | Note Added: 0014534 | |
13-08-2014 13:27 | T_Im | Status | feedback => assigned |
13-08-2014 13:27 | T_Im | Note Edited: 0014534 | View Revisions |
13-08-2014 13:53 | vdemidov | Status | assigned => resolved |
13-08-2014 13:53 | vdemidov | Fixed in Version | => 141111 |
13-08-2014 13:53 | vdemidov | Resolution | open => fixed |
13-08-2014 13:55 | vdemidov | Target Version | => 141111 |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |