View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001938 | SAS.Планета | Хотелка / Feature request | public | 28-05-2013 12:29 | 20-06-2013 06:59 |
| Reporter | Parasite | Assigned To | zed | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | Server | OS Version | 2003 |
| Product Version | 121010 | ||||
| Target Version | 131111 | Fixed in Version | 131111 | ||
| Summary | 0001938: Беркли: При переключении на другую карту - снимать локи и делать Detach предыдущей | ||||
| Description | Возможно, это фича - но очень мешает жить. При наличии нескольких карт в Беркли и активном переключении между ними - САС "забывает" демонтировать предыдущий используемый кэш при открытии нового. В итоге все единожды используемые (даже на чтение) карты висят открытыми\залоченными под использование САСом, и висят они ровно до рестарта САСа. Это мало того что пожирает память и хэндлеры, так еще и мешает производить какие-либо операции с неиспользуемым в настоящее время кэшем (например, полностью его убить), так еще и, внимание - при малейшем сбое САСа\Беркли\системы - портятся все уже открытые карты, даже если мы с ними уже давно не работаем. Портятся потому, что базовод их все не закрывает их так как положено. Это причина, по которой я поставил "Серъезность: высокая" данному тикету. | ||||
| Steps To Reproduce | 1. Поиметь 2 любых кэша в Беркли. 2. Поработать с одним, даже на просмотр. Всё ОК, всё работает. 3. Не выходя из САСа, переключиться на вторую карту. Всё ОК, все работает. 4. Посмотреть открытые хэндлеры на папку с 1й картой (например, через Unlocker). 5. Поразиться тому, что там около десятка открытых файлов - причем открытых как R\W. 6. Опционально: скрэшить САСа и проверить оба кэша на ошибки. Убедиться, что они там есть как пинимум по ENV+LSN. :( | ||||
| Additional Information | Хотелка 1874 растет как раз из-за порчи кэша Беркли при малейшем сбое, даже если записи в него не планируется. Если разрабы посчитают, что эти оба два тикета как-то связаны - пускай прилинкуют. | ||||
| Tags | No tags attached. | ||||
|
|
Ну, сразу отмонтировать и сбрасывать все кэши перебор, а вот отрубанине секунд через 30 после последнего использования вполне можно было бы реализовать, если оно еще не реализовано. |
|
|
Давно были такие мысли, но не сообразил, как сообщить хранилищу, что его уже не используют, а переключились на другую карту. |
|
|
А никак ему сообщать не нужно. Только по таймауту с последнего обращения. |
|
|
>сразу отмонтировать и сбрасывать все кэши перебор, а вот отрубанине секунд через 30 после последнего использования вполне можно было бы реализовать Не все, а только тот с которого и переключаемся. То есть - всегда один за раз. То есть, по событию "Карта\слой переключены\отключены" - проверять\форсировать полное закрытие предыдущего хранилища перед открытием нового, да и всё. Ну, по крайней мере я это так вижу. :) >Только по таймауту с последнего обращения. Тогда будем получать Detach кэша даже если карту не меняли - а просто отошли покурить. |
|
|
>>Только по таймауту с последнего обращения. >Тогда будем получать Detach кэша даже если карту не меняли - а просто отошли покурить. Вот-вот. Нужно более продуманное поведение, а не тупо по таймауту. |
|
|
Более продуманное будет на порядок сложнее и менее надежным. Просто обращаться к карте быть не только тогда когда она отображается в основном окне, но и тогда когда она открыта в миникарте, или когда идет закачка по региону, или когда идет склейка, или экспорт и еще куча случаев, которые можно забыть или которые появятся позже. А закрытие файлов по вменяемому таймауту вполне себе хорошая штука. Ну будет пауза в пол секунды после возвращения с перекура и что? Это будет не баг, а фитча, зато если в это время комп помрет, то кэш не попортится даже если карта была включена. |
|
|
> или когда идет закачка по региону, или когда идет склейка, или экспорт и еще куча случаев В этих случаях как раз-таки задержка не критична и можно закрывать по таймауту, если юзер не юзает в гуе данную карту. Т.е. по хорошему, в хранилище нужно слать евент "юзер включил/выключил карту", а дальше оно уже пускай само думает. >А закрытие файлов по вменяемому таймауту вполне себе хорошая штука. Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек. |
|
|
>>А закрытие файлов по вменяемому таймауту вполне себе хорошая штука. > Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек. Та ну ладно. Сколько открытие базы занимает? Максимум пару секунд. Таймаут 30 секунд конечно перебор, а пара минут полного бездействия вполне себе повод закрыть все открытые файлы. PS: То что ты хочешь сделать может где-то и будет чуток эффективнее, но очень редко и дофига мороки, а простой таймаут закроет 95% проблем и делаетася практически элементарно. Но я не настаиваю. Можно оставить как есть. Меня это не напрягает. |
|
|
>Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек. Цимес момента в данном конкретном тикете в том, чтобы отключать неиспользуемую карту по возможности МОМЕНТАЛЬНО. Толку от введения отключения через час - если еще час оно будет висеть в памяти, со всеми своими последствиями при случайном крэше за тот самый час? И уже не используемый кэш с диска я еще целый час не смогу убить иначе, кроме как выйдя с саса? То есть, будет то же самое что в шапке тикета и так. Если нельзя ввести цивилизованными методами с передачей в хранилище - тогда имхо лучше короткий таймаут имени вдемидова, чем часовой имени зеда. 30 сек это конечно сильно круто, посему предлагаю 3 минуты (как на сетевые операции) или 5. Либо, сугубо на правах маразма - вообще открывать любой беркли по умолчанию как R\O и держать его так ровно до тех пор, пока не приспичит вносить изменения (и там - таймаут на R\W режим). Имею мнение, что 99% времени юзания любого кэша как раз на чтение - ну так и открывать его именно в нем, и пускай себе сас крешится сколько угодно. |
|
|
>а пара минут полного бездействия вполне себе повод закрыть все открытые файлы. Вопрос: как будет отрабатываться ситуация "активно работаем (таймаута по САСу нет и не планируется), а карту уже переключили и работаем с другой"? С первой локи кто снимет-то при этом, НЕ ТРОГАЯ вторую? |
|
|
>Сколько открытие базы занимает? Зависит от скорости носителя. Но лаг таки присутствует в любом случае. >С первой локи кто снимет-то при этом, НЕ ТРОГАЯ вторую? Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env). |
|
|
>Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. Кем они закроются, если юзер сидит за САСом и ворочает мышкой - но уже по ДРУГОЙ карте? Глобального таймаута ж не случится. Или предлагается ввести разные таймауты по каждой отдельной карте? |
|
|
Я предлагал таймауты по каждой отдельной карте, но я не в курсе таких особенностей беркли как: > Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env). ИМХО Env должен быть привязан к карте, а не быть общим на все карты. |
|
|
>Кем они закроются, если юзер сидит за САСом и ворочает мышкой - но уже по ДРУГОЙ карте? Внутренним САС-овским механизмом. Каждому файлу БД задаётся TTL (=5мин), по которому они закрываются. В конце концов, можно назначить TTL и для env, с тем же интервалом, но в env, помимо прочего, хранится свой RAM-кэш, который при этом будет сбрасываться на диск, а потом (при открытии) опять подгружаться. Отсюда и лаг. >ИМХО Env должен быть привязан к карте, а не быть общим на все карты. Ну так оно так и есть. С единственной оговоркой, что если у юзера несколько карт используют один и тот же кэш, то у этих карт будет общий env. |
|
|
>Я предлагал таймауты по каждой отдельной карте Ага. Тогда - да, сработает. Но зато придется вводить кучку таймеров по числу установленных у юзера карт, и тикать их таки все оптом... Впрочем, это уже на усмотрение программеров. >Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env). Вот по таймауту и делать полную выгрузку этого всего. А там - пускай САС крешится, абсолютно ничего не будет потеряно даже если он так под таймаутом месяц стоять будет. Главное, чтобы таймаут не срабатывал когда закачка в карты ночами идет (при отсутствии юзера и его активности по карте). :) |
|
|
>Каждому файлу БД задаётся TTL (=5мин), по которому они закрываются. =наверное будет безбожно тормозить на больших кэшах (лично у меня тысячи и тысячи файлов баз под одним САСом например). >Отсюда и лаг. Некоторый лаг, разумеется, будет. Никто не спорит. Ну и пусть его - это маленькая цена, когда весь кэш по всем картам может накрыться медным тазом если свет случайно мигнул. Можно вообще САСовый экран бланковать черным и писать "Тут был скринсейвер", и перерисовывать когда уже всё подчитано с диска. Но это погремушки конечно - лично я согласен и на лаг. :) |
|
|
>наверное будет безбожно тормозить на больших кэшах C чего-бы? Тем более, что я описываю реализованное поведение кэша, которое ты можешь наблюдать на своих "тысячах тысяч" файлов баз. |
|
|
>C чего-бы? Тем более, что я описываю реализованное поведение кэша Так я ж не утверждал - я спрашивал. Раз не будет, то и отлично. |
|
|
Ну ИМХО через минуту после отстрела последней базы тайлохранилища по TTL можно и env отстреливать. А при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу |
|
|
>при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу значит должно быть больше чем таймаут на сетевые операции |
|
|
>>при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу > значит должно быть больше чем таймаут на сетевые операции Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают. |
|
|
>Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают. Может быть например 50 одновременных закачек по медленному каналу с тормознутого сервиса. Тогда погода будет. |
|
|
>>Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают. > Может быть например 50 одновременных закачек по медленному каналу с тормознутого сервиса. Тогда погода будет. Тогда таймаута в 5 минут между записями не будет и соответственно вообще разницы не будет. |
|
|
>и соответственно вообще разницы не будет Видимо пока не налетишь сам - не поймёшь, что возможен весь промежуточный спектр значений. Суть в том, что отрубание будет раз в минуту, и раз в 70сек будут тайлы например прилетать при таймауте в 5 минут - и в итоге перед каждым тайлом будет переоткрытие базы. |
|
|
Не уловил причины, по которой тайлохранилище будет отрубатьтся через минуту если речь шла об отключении через минуту после таймаута последней базы, которые отключаются через 5 минут. И не забываем что перед скачкой каждого тайла проверяется его наличие в базе, тоесть будет обращение, которое не даст отстрелить базу. |
|
|
>после таймаута последней базы, которые отключаются через 5 минут Так тут вроде как речь шла об уменьшении 5-минутного интервала? |
|
|
Если я буду делать этот тикет, то только как изначально и было описано - при отключении карты в гуе + таймаут в несколько минут после отключения. А просто так, по таймауту, я не хочу чтобы у меня карта отваливалась каждые 5 минут бездействия. |
|
|
Тогда сразу ставь won't fix, так как тайлохранилище не должно знать кто его использует, не его это дело. |
|
|
>не его это дело Зашибись. Походу надо сворачиваться и уходить в SACS с концами. |
|
|
>так как тайлохранилище не должно знать кто его использует Мсье видимо имел в виду, что тайлохранилище не должно знать, кто будет дёргать его Sync? Ну тогда имеет смысл добавить Payload в Sync. >не хочу чтобы у меня карта отваливалась каждые 5 минут бездействия Соответственно, можно решить опцией, тушить включённые карты и слои по какому-то времени, или нет. |
|
|
>Мсье видимо имел в виду Самое интересное, что о том, как это может быть реализовано ещё небыло сказано ни слова, а уже предлагается закрыть тикет без обсуждений. |
|
|
>Мсье видимо имел в виду, что тайлохранилище не должно знать, кто будет дёргать его Sync? Ну тогда имеет смысл добавить Payload в Sync. Что за Sync и что за Payload? >Зашибись. Походу надо сворачиваться и уходить в SACS с концами. Это будет печально. ИМХО тайлохранилище не должно знать кто и как его использует. Поэтому получается два варианта: 1. вводить пару методов StartUsing/FinshUsing и везде где начинаем работу с каким-то тайлохранилищем дергать первый, а по завершении второй. И в тайлохранилище вести подсчет вызовов и допускать таймаут только если никто не пользует. 2. вводить для ГУЯ отдельную пинговалку которая будет дергать тайлохранилища открытых на экране карт не двавая им отвалится по таймауту. Оба варианта на мой взгляд сопряжены с большой морокой, но первый более подвержен ошибкам. |
|
|
>Это будет печально. Ну так нефиг любую творческую мысль рубить на корню. >Поэтому получается два варианта О, уже оказывается и аж два приемлемых варианта нашлись. И это сходу. |
|
|
>>Это будет печально. > Ну так нефиг любую творческую мысль рубить на корню. Так нефиг на любую фразу обижаться. Обзови придурком и агрументируй свою позицию - я не обижусь, но толькое если позиция будет аргументированной. :) >О, уже оказывается и аж два приемлемых варианта нашлись. И это сходу. И первый из этих двух захламляет код использования тайлохранилища, а второй все равно добавлять потом, после того как сделать простое отстреливаение по таймауту. И все это ради пары секунд после 5 минутного перекура? Зачем? Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд? |
|
|
>И первый из этих двух Вообще-то у меня есть свой вариант - сделать ленивое создание и соответствующее удаление хранилища целиком. У нас хранилище сидит в TMapType и все обращения к нему идут через карту. Так вот именно тут, мы можем легко управлять временем жизни хранилища, не создавать его при создании карты, а только по запросу, удалять исходя из активность карты (не кэша) и тому подобное. Причём, польза будет не только для Беркли. >Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд? Просто я не хочу лагов даже в секунду. |
|
|
>У нас хранилище сидит в TMapType и все обращения к нему идут через карту. Так вот именно тут, мы можем легко управлять временем жизни хранилища, не создавать его при создании карты, а только по запросу, удалять исходя из активность карты (не кэша) и тому подобное. Но карта тоже не знает и знать не должна активна ли она сейчас в пользовательском интерфейсе, поэтому опять приходим к тем двум вариантам, которые я уже озувучил. >Просто я не хочу лагов даже в секунду. Тебе жалко пары секунд после пятиминутной паузы? Да экран дольше включается после скринсейвера. Давай поспорим, что никто разницы не заметит? |
|
|
>Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд? Ну вообще говоря да, коннект к СУБД может быть и пару секунд и больше, а потом работа быстрая, зависит от особенностей работы и настройки (например, пока нет в кэше DSN или ARP будет дольше на разрешение соответствующего адреса). >Что за Sync и что за Payload? Sync - проца в тайлохранилище. Payload - буквально - полезная нагрузка (параметр). В простейшем случае Boolean. В более сложном - IInterface и прочие извращения. >второй все равно добавлять потом Ну собственно да, поэтому я и предложил Sync по активным картам и слоям. Фабрика SyncPayload может генерить Payload на основании в том числе информации об активных картах. Программной опцией на неё можно влиять, генерить ей всегда False, или же True если карта активна (если тип будет Boolean, сюда же можно и время вырубания даже активной карты пропихнуть). Соответственно в хранилище этот Payload воспринимается как запрет вырубать карту (ну или с точностью до наоборот). Логика чуть более чем тривиальная, кодится тоже несложно. |
|
|
>Ну собственно да, поэтому я и предложил Sync по активным картам и слоям. > Фабрика SyncPayload может генерить Payload на основании в том числе информации об активных картах. Программной опцией на неё можно влиять, генерить ей всегда False, или же True если карта активна (если тип будет Boolean, сюда же можно и время вырубания даже активной карты пропихнуть). Соответственно в хранилище этот Payload воспринимается как запрет вырубать карту (ну или с точностью до наоборот). Логика чуть более чем тривиальная, кодится тоже несложно. Ну в общем, я тоже склоняюсь к варианту с пинговалкой. А он вполне себе ортогонален к реализации данной хотелки. |
|
|
Сейчас будет логика такая: каждые 5 минут или каждые 1000 коммитов (операции Write и Delete) будет выполняться проверка TTL файлов БД. Если к БД обращались более 1 минуты назад (тот самый TTL), она считается не нужной и закрывается. Если все БД оказались не нужными и закрылись, то тут же закрывается и env. Если хотя бы одна БД ещё живая - ждём ещё 5 мин или 1000 коммитов и проверяем опять. И что ещё важно, при каждой такой синхронизации инициализируется сброс данных из лога транзакций в БД (поэтому синхронизация и завязана дополнительно на коммиты). При активной записи в кэш, через тот же Менеджер кэша, если не мониторить коммиты, то логи распухают моментально до сотен мегобайт. Посмотрим, как кэш будет вести себя в таком режиме, и если что, озаботимся пинговалгой, чтобы env у активной карты не умирал. |
|
|
>Если к БД обращались более 1 минуты назад (тот самый TTL), она считается не нужной и закрывается. Имхо, 1 минута - весьма мало. Будет постоянно переоткрываться\перезакрываться даже если юзер просто внимательно на экране что-то рассматривает - или, например, ставит новую метку... Предлагаю 3 или даже 5 минут, и сразу с env (ниже). >Если все БД оказались не нужными и закрылись, то тут же закрывается и env. А разве env у нас не отдельный к каждой карте? Зачем ждать закрытия всех карт - для закрытия конкретного env? |
|
|
> Предлагаю 3 или даже 5 минут, и сразу с env (ниже). Мне тоже кажется, что 1 минута маловато, а то что этот период гораздо меньше периода проверки вобще сделает его слегка непредсказуемым. Может наоборот, проверять раз в минуту, а время жизни минут 5 поставить? >А разве env у нас не отдельный к каждой карте? Зачем ждать закрытия всех карт - для закрытия конкретного env? При чем тут все карты, речь про закрытие всех баз одной карты. |
|
|
>При чем тут все карты, речь про закрытие всех баз одной карты. Фразу "Если все БД оказались не нужными и закрылись, то тут же закрывается и env" я понял в ключе "ВООБЩЕ ВСЕ БД". Если имелась ввиду только одна карта - то ОК. |
|
|
Вообще, я хочу вынести все эти интервалы в конфиг, вместе с настройкой ReadOnly доступа (см. 0001874), тогда можно будет экспериментировать и подбирать оптимальные значения при желании. >Имхо, 1 минута - весьма мало. А там так и было. Фраза "Сейчас будет логика такая" не обязательно означает, что до этого логика была какая-то принципиально другая. По сути, всё что я добавил - закрытие env, если закрыты все БД (данной карты). А интервалы синхронизации я не трогал. >Может наоборот, проверять раз в минуту, а время жизни минут 5 поставить? Не, синхронизация ж кроме всего прочего инициализирует сброс кэша. А минута это довольно часто. Хотя, если часто сбрасывать кэш, то и операция эта будет достаточно быстрой, ввиду малого объёма закэшированных данных. Ситуация с частым закрытием/открытием БД сглаживается тем, что у нас ещё есть кэш в env. Так что, теоретически (хотя, может я и ошибаюсь), файл БД может быть ещё не закрыт, даже если из САСа мы вдруг отключились от этой БД. Но с уверенностью могу сказать, что даже если файл БД закрывается и из env, в кэше всё равно остаются страницы из того файла, вплоть до закрытия/открытия самого env. Исходя из этого, я и озаботился увеличением кэша env через DB_CONFIG |
|
|
>>Имхо, 1 минута - весьма мало. >А там так и было. Фраза "Сейчас будет логика такая" не обязательно означает, что до этого логика была какая-то принципиально другая. Как показывает практика, "до этого" (то есть - вот прямо сейчас) при крэше САСа файлы БД бились даже у той карты, отключение от которой было (на момент крэша) довольно давно. Скажем - час. Если бы оно [сейчас] закрывалось через минуту - при крэше через час бился бы только env. Я неправ? >я хочу вынести все эти интервалы в конфиг Это было бы идеальным. |
|
|
>Если бы оно [сейчас] закрывалось через минуту - при крэше через час бился бы только env. Я неправ? В кэше Беркли, env - всему голова. И эта "голова" сидит в RAM и по возможности держит там страницы когда-либо открываемых БД. В том числе держит и изменения этих страниц, и в зависимости от настроек, закрывая БД из САС нет гарантии, что все изменения тут же залетят в БД. Оно может там всё так же висеть в RAM до второго пришествия. Поэтому при крэше env, может всё полететь к чертям. Вот тут я постарался подробно расписать настройки env, которые могут влиять на то, с какой скоростью всё может полететь к чертям, при крэше чего-либо. |
|
|
>Оно может там всё так же висеть в RAM до второго пришествия. Поэтому при крэше env, может всё полететь к чертям. Вот именно поэтому я и предлагаю закрывать беркли вместе с env через 3..5 мин, а не ступенчато (сперва - файлы, а потом - env). Ибо если оно скрэшится на этом промежутке - еррор все равно будет (env не закрыт) независимо от того, закрыты были уже файлы к тому времени или нет. В общем - ждем реализации, а там тайминги уже оттюним как надо. |
|
|
>В общем - ждем реализации Так реализовано уже. Через 5 минут бездействия, гарантированно закрываются все БД и env. |
|
|
>Так реализовано уже. В сегодняшней ночнушке? ОК, будем покачать и попробовать. :) |
|
|
В завтрашней ночнушке можно будет пробовать изменять интервалы синхронизации через ini файл: http://sasgis.org/mantis/view.php?id=1874#c11663 |
|
|
>Через 5 минут бездействия, гарантированно закрываются все БД и env. Вроде работает так как надо. При "просыпании" карты - наблюдается предсказуемый, но вполне терпимый лаг ~1сек. Спасибо. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 28-05-2013 12:29 | Parasite | New Issue | |
| 28-05-2013 13:28 | vdemidov | Note Added: 0011428 | |
| 28-05-2013 14:44 | zed | Note Added: 0011429 | |
| 28-05-2013 16:52 | vdemidov | Note Added: 0011430 | |
| 29-05-2013 02:44 | Parasite | Note Added: 0011432 | |
| 29-05-2013 04:43 | zed | Note Added: 0011433 | |
| 29-05-2013 05:21 | vdemidov | Note Added: 0011434 | |
| 29-05-2013 05:29 | zed | Note Added: 0011435 | |
| 29-05-2013 05:57 | vdemidov | Note Added: 0011436 | |
| 29-05-2013 06:00 | vdemidov | Note Edited: 0011436 | |
| 29-05-2013 06:02 | Parasite | Note Added: 0011437 | |
| 29-05-2013 06:08 | Parasite | Note Added: 0011438 | |
| 29-05-2013 06:08 | Parasite | Note Edited: 0011438 | |
| 29-05-2013 06:30 | zed | Note Added: 0011439 | |
| 29-05-2013 06:35 | Parasite | Note Added: 0011440 | |
| 29-05-2013 06:40 | vdemidov | Note Added: 0011442 | |
| 29-05-2013 06:55 | zed | Note Added: 0011443 | |
| 29-05-2013 06:56 | zed | Note Edited: 0011443 | |
| 29-05-2013 06:57 | Parasite | Note Added: 0011444 | |
| 29-05-2013 07:03 | Parasite | Note Added: 0011445 | |
| 29-05-2013 07:03 | Parasite | Note Edited: 0011444 | |
| 29-05-2013 07:10 | zed | Note Added: 0011447 | |
| 29-05-2013 07:13 | Parasite | Note Added: 0011448 | |
| 29-05-2013 07:58 | vdemidov | Note Added: 0011449 | |
| 29-05-2013 07:58 | vdemidov | Note Edited: 0011449 | |
| 29-05-2013 10:01 | vasketsov | Note Added: 0011450 | |
| 29-05-2013 10:20 | vdemidov | Note Added: 0011451 | |
| 29-05-2013 19:53 | vdemidov | Assigned To | => zed |
| 29-05-2013 19:53 | vdemidov | Status | new => assigned |
| 29-05-2013 19:54 | vdemidov | Product Version | .Nightly => 121010 |
| 29-05-2013 19:54 | vdemidov | Target Version | => 41xxxx |
| 29-05-2013 22:03 | vasketsov | Note Added: 0011461 | |
| 30-05-2013 05:17 | vdemidov | Note Added: 0011462 | |
| 30-05-2013 21:01 | vasketsov | Note Added: 0011469 | |
| 31-05-2013 05:25 | vdemidov | Note Added: 0011470 | |
| 31-05-2013 07:37 | vasketsov | Note Added: 0011471 | |
| 31-05-2013 18:17 | zed | Category | Баг => Хотелка |
| 03-06-2013 08:29 | zed | Note Added: 0011482 | |
| 03-06-2013 09:24 | vdemidov | Note Added: 0011483 | |
| 03-06-2013 09:29 | zed | Note Added: 0011484 | |
| 03-06-2013 09:48 | vasketsov | Note Added: 0011486 | |
| 03-06-2013 09:49 | vasketsov | Note Edited: 0011486 | |
| 03-06-2013 10:31 | zed | Note Added: 0011488 | |
| 03-06-2013 10:36 | vdemidov | Note Added: 0011489 | |
| 03-06-2013 10:44 | zed | Note Added: 0011490 | |
| 03-06-2013 11:03 | vdemidov | Note Added: 0011491 | |
| 03-06-2013 11:12 | zed | Note Added: 0011492 | |
| 03-06-2013 11:38 | vdemidov | Note Added: 0011493 | |
| 03-06-2013 11:56 | vasketsov | Note Added: 0011494 | |
| 03-06-2013 14:48 | vdemidov | Note Added: 0011495 | |
| 10-06-2013 17:47 | zed | Note Added: 0011625 | |
| 10-06-2013 17:47 | zed | Status | assigned => feedback |
| 10-06-2013 17:50 | zed | Note Edited: 0011625 | |
| 11-06-2013 02:40 | Parasite | Note Added: 0011629 | |
| 11-06-2013 02:40 | Parasite | Status | feedback => assigned |
| 11-06-2013 02:40 | Parasite | Note Edited: 0011629 | |
| 11-06-2013 07:12 | vdemidov | Note Added: 0011632 | |
| 11-06-2013 07:23 | Parasite | Note Added: 0011633 | |
| 11-06-2013 08:34 | zed | Note Added: 0011635 | |
| 11-06-2013 08:41 | Parasite | Note Added: 0011636 | |
| 11-06-2013 08:57 | zed | Note Added: 0011638 | |
| 11-06-2013 09:20 | Parasite | Note Added: 0011639 | |
| 11-06-2013 09:25 | zed | Note Added: 0011640 | |
| 11-06-2013 09:30 | Parasite | Note Added: 0011641 | |
| 14-06-2013 12:20 | zed | Note Added: 0011664 | |
| 15-06-2013 15:56 | zed | Status | assigned => resolved |
| 15-06-2013 15:56 | zed | Fixed in Version | => 131111 |
| 15-06-2013 15:56 | zed | Resolution | open => fixed |
| 17-06-2013 04:56 | Parasite | Note Added: 0011675 | |
| 20-06-2013 06:59 | vdemidov | Target Version | 41xxxx => 131111 |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |