0001938: Беркли: При переключении на другую карту - снимать локи и делать Detach предыдущей

Notes
(0011428) vdemidov (manager) 28-05-2013 13:28	Ну, сразу отмонтировать и сбрасывать все кэши перебор, а вот отрубанине секунд через 30 после последнего использования вполне можно было бы реализовать, если оно еще не реализовано.

(0011429) zed (manager) 28-05-2013 14:44	Давно были такие мысли, но не сообразил, как сообщить хранилищу, что его уже не используют, а переключились на другую карту.

(0011430) vdemidov (manager) 28-05-2013 16:52	А никак ему сообщать не нужно. Только по таймауту с последнего обращения.

(0011432) Parasite (administrator) 29-05-2013 02:44	>сразу отмонтировать и сбрасывать все кэши перебор, а вот отрубанине секунд через 30 после последнего использования вполне можно было бы реализовать Не все, а только тот с которого и переключаемся. То есть - всегда один за раз. То есть, по событию "Карта\слой переключены\отключены" - проверять\форсировать полное закрытие предыдущего хранилища перед открытием нового, да и всё. Ну, по крайней мере я это так вижу. :) >Только по таймауту с последнего обращения. Тогда будем получать Detach кэша даже если карту не меняли - а просто отошли покурить.

(0011433) zed (manager) 29-05-2013 04:43	>>Только по таймауту с последнего обращения. >Тогда будем получать Detach кэша даже если карту не меняли - а просто отошли покурить. Вот-вот. Нужно более продуманное поведение, а не тупо по таймауту.

(0011434) vdemidov (manager) 29-05-2013 05:21	Более продуманное будет на порядок сложнее и менее надежным. Просто обращаться к карте быть не только тогда когда она отображается в основном окне, но и тогда когда она открыта в миникарте, или когда идет закачка по региону, или когда идет склейка, или экспорт и еще куча случаев, которые можно забыть или которые появятся позже. А закрытие файлов по вменяемому таймауту вполне себе хорошая штука. Ну будет пауза в пол секунды после возвращения с перекура и что? Это будет не баг, а фитча, зато если в это время комп помрет, то кэш не попортится даже если карта была включена.

(0011435) zed (manager) 29-05-2013 05:29	> или когда идет закачка по региону, или когда идет склейка, или экспорт и еще куча случаев В этих случаях как раз-таки задержка не критична и можно закрывать по таймауту, если юзер не юзает в гуе данную карту. Т.е. по хорошему, в хранилище нужно слать евент "юзер включил/выключил карту", а дальше оно уже пускай само думает. >А закрытие файлов по вменяемому таймауту вполне себе хорошая штука. Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек.

(0011436) vdemidov (manager) 29-05-2013 05:57 edited on: 29-05-2013 06:00	>>А закрытие файлов по вменяемому таймауту вполне себе хорошая штука. > Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек. Та ну ладно. Сколько открытие базы занимает? Максимум пару секунд. Таймаут 30 секунд конечно перебор, а пара минут полного бездействия вполне себе повод закрыть все открытые файлы. PS: То что ты хочешь сделать может где-то и будет чуток эффективнее, но очень редко и дофига мороки, а простой таймаут закроет 95% проблем и делаетася практически элементарно. Но я не настаиваю. Можно оставить как есть. Меня это не напрягает.

(0011437) Parasite (administrator) 29-05-2013 06:02	>Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек. Цимес момента в данном конкретном тикете в том, чтобы отключать неиспользуемую карту по возможности МОМЕНТАЛЬНО. Толку от введения отключения через час - если еще час оно будет висеть в памяти, со всеми своими последствиями при случайном крэше за тот самый час? И уже не используемый кэш с диска я еще целый час не смогу убить иначе, кроме как выйдя с саса? То есть, будет то же самое что в шапке тикета и так. Если нельзя ввести цивилизованными методами с передачей в хранилище - тогда имхо лучше короткий таймаут имени вдемидова, чем часовой имени зеда. 30 сек это конечно сильно круто, посему предлагаю 3 минуты (как на сетевые операции) или 5. Либо, сугубо на правах маразма - вообще открывать любой беркли по умолчанию как R\O и держать его так ровно до тех пор, пока не приспичит вносить изменения (и там - таймаут на R\W режим). Имею мнение, что 99% времени юзания любого кэша как раз на чтение - ну так и открывать его именно в нем, и пускай себе сас крешится сколько угодно.

(0011438) Parasite (administrator) 29-05-2013 06:08 edited on: 29-05-2013 06:08	>а пара минут полного бездействия вполне себе повод закрыть все открытые файлы. Вопрос: как будет отрабатываться ситуация "активно работаем (таймаута по САСу нет и не планируется), а карту уже переключили и работаем с другой"? С первой локи кто снимет-то при этом, НЕ ТРОГАЯ вторую?

(0011439) zed (manager) 29-05-2013 06:30	>Сколько открытие базы занимает? Зависит от скорости носителя. Но лаг таки присутствует в любом случае. >С первой локи кто снимет-то при этом, НЕ ТРОГАЯ вторую? Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env).

(0011440) Parasite (administrator) 29-05-2013 06:35	>Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. Кем они закроются, если юзер сидит за САСом и ворочает мышкой - но уже по ДРУГОЙ карте? Глобального таймаута ж не случится. Или предлагается ввести разные таймауты по каждой отдельной карте?

(0011442) vdemidov (manager) 29-05-2013 06:40	Я предлагал таймауты по каждой отдельной карте, но я не в курсе таких особенностей беркли как: > Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env). ИМХО Env должен быть привязан к карте, а не быть общим на все карты.

(0011443) zed (manager) 29-05-2013 06:55 edited on: 29-05-2013 06:56	>Кем они закроются, если юзер сидит за САСом и ворочает мышкой - но уже по ДРУГОЙ карте? Внутренним САС-овским механизмом. Каждому файлу БД задаётся TTL (=5мин), по которому они закрываются. В конце концов, можно назначить TTL и для env, с тем же интервалом, но в env, помимо прочего, хранится свой RAM-кэш, который при этом будет сбрасываться на диск, а потом (при открытии) опять подгружаться. Отсюда и лаг. >ИМХО Env должен быть привязан к карте, а не быть общим на все карты. Ну так оно так и есть. С единственной оговоркой, что если у юзера несколько карт используют один и тот же кэш, то у этих карт будет общий env.

(0011444) Parasite (administrator) 29-05-2013 06:57 edited on: 29-05-2013 07:03	>Я предлагал таймауты по каждой отдельной карте Ага. Тогда - да, сработает. Но зато придется вводить кучку таймеров по числу установленных у юзера карт, и тикать их таки все оптом... Впрочем, это уже на усмотрение программеров. >Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env). Вот по таймауту и делать полную выгрузку этого всего. А там - пускай САС крешится, абсолютно ничего не будет потеряно даже если он так под таймаутом месяц стоять будет. Главное, чтобы таймаут не срабатывал когда закачка в карты ночами идет (при отсутствии юзера и его активности по карте). :)

(0011445) Parasite (administrator) 29-05-2013 07:03	>Каждому файлу БД задаётся TTL (=5мин), по которому они закрываются. =наверное будет безбожно тормозить на больших кэшах (лично у меня тысячи и тысячи файлов баз под одним САСом например). >Отсюда и лаг. Некоторый лаг, разумеется, будет. Никто не спорит. Ну и пусть его - это маленькая цена, когда весь кэш по всем картам может накрыться медным тазом если свет случайно мигнул. Можно вообще САСовый экран бланковать черным и писать "Тут был скринсейвер", и перерисовывать когда уже всё подчитано с диска. Но это погремушки конечно - лично я согласен и на лаг. :)

(0011447) zed (manager) 29-05-2013 07:10	>наверное будет безбожно тормозить на больших кэшах C чего-бы? Тем более, что я описываю реализованное поведение кэша, которое ты можешь наблюдать на своих "тысячах тысяч" файлов баз.

(0011448) Parasite (administrator) 29-05-2013 07:13	>C чего-бы? Тем более, что я описываю реализованное поведение кэша Так я ж не утверждал - я спрашивал. Раз не будет, то и отлично.

(0011449) vdemidov (manager) 29-05-2013 07:58 edited on: 29-05-2013 07:58	Ну ИМХО через минуту после отстрела последней базы тайлохранилища по TTL можно и env отстреливать. А при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу

(0011450) vasketsov (manager) 29-05-2013 10:01	>при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу значит должно быть больше чем таймаут на сетевые операции

(0011451) vdemidov (manager) 29-05-2013 10:20	>>при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу > значит должно быть больше чем таймаут на сетевые операции Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают.

(0011461) vasketsov (manager) 29-05-2013 22:03	>Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают. Может быть например 50 одновременных закачек по медленному каналу с тормознутого сервиса. Тогда погода будет.

(0011462) vdemidov (manager) 30-05-2013 05:17	>>Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают. > Может быть например 50 одновременных закачек по медленному каналу с тормознутого сервиса. Тогда погода будет. Тогда таймаута в 5 минут между записями не будет и соответственно вообще разницы не будет.

(0011469) vasketsov (manager) 30-05-2013 21:01	>и соответственно вообще разницы не будет Видимо пока не налетишь сам - не поймёшь, что возможен весь промежуточный спектр значений. Суть в том, что отрубание будет раз в минуту, и раз в 70сек будут тайлы например прилетать при таймауте в 5 минут - и в итоге перед каждым тайлом будет переоткрытие базы.

(0011470) vdemidov (manager) 31-05-2013 05:25	Не уловил причины, по которой тайлохранилище будет отрубатьтся через минуту если речь шла об отключении через минуту после таймаута последней базы, которые отключаются через 5 минут. И не забываем что перед скачкой каждого тайла проверяется его наличие в базе, тоесть будет обращение, которое не даст отстрелить базу.

(0011471) vasketsov (manager) 31-05-2013 07:37	>после таймаута последней базы, которые отключаются через 5 минут Так тут вроде как речь шла об уменьшении 5-минутного интервала?

(0011482) zed (manager) 03-06-2013 08:29	Если я буду делать этот тикет, то только как изначально и было описано - при отключении карты в гуе + таймаут в несколько минут после отключения. А просто так, по таймауту, я не хочу чтобы у меня карта отваливалась каждые 5 минут бездействия.

(0011483) vdemidov (manager) 03-06-2013 09:24	Тогда сразу ставь won't fix, так как тайлохранилище не должно знать кто его использует, не его это дело.

(0011484) zed (manager) 03-06-2013 09:29	>не его это дело Зашибись. Походу надо сворачиваться и уходить в SACS с концами.

(0011486) vasketsov (manager) 03-06-2013 09:48 edited on: 03-06-2013 09:49	>так как тайлохранилище не должно знать кто его использует Мсье видимо имел в виду, что тайлохранилище не должно знать, кто будет дёргать его Sync? Ну тогда имеет смысл добавить Payload в Sync. >не хочу чтобы у меня карта отваливалась каждые 5 минут бездействия Соответственно, можно решить опцией, тушить включённые карты и слои по какому-то времени, или нет.

(0011488) zed (manager) 03-06-2013 10:31	>Мсье видимо имел в виду Самое интересное, что о том, как это может быть реализовано ещё небыло сказано ни слова, а уже предлагается закрыть тикет без обсуждений.

(0011489) vdemidov (manager) 03-06-2013 10:36	>Мсье видимо имел в виду, что тайлохранилище не должно знать, кто будет дёргать его Sync? Ну тогда имеет смысл добавить Payload в Sync. Что за Sync и что за Payload? >Зашибись. Походу надо сворачиваться и уходить в SACS с концами. Это будет печально. ИМХО тайлохранилище не должно знать кто и как его использует. Поэтому получается два варианта: 1. вводить пару методов StartUsing/FinshUsing и везде где начинаем работу с каким-то тайлохранилищем дергать первый, а по завершении второй. И в тайлохранилище вести подсчет вызовов и допускать таймаут только если никто не пользует. 2. вводить для ГУЯ отдельную пинговалку которая будет дергать тайлохранилища открытых на экране карт не двавая им отвалится по таймауту. Оба варианта на мой взгляд сопряжены с большой морокой, но первый более подвержен ошибкам.

(0011490) zed (manager) 03-06-2013 10:44	>Это будет печально. Ну так нефиг любую творческую мысль рубить на корню. >Поэтому получается два варианта О, уже оказывается и аж два приемлемых варианта нашлись. И это сходу.

(0011491) vdemidov (manager) 03-06-2013 11:03	>>Это будет печально. > Ну так нефиг любую творческую мысль рубить на корню. Так нефиг на любую фразу обижаться. Обзови придурком и агрументируй свою позицию - я не обижусь, но толькое если позиция будет аргументированной. :) >О, уже оказывается и аж два приемлемых варианта нашлись. И это сходу. И первый из этих двух захламляет код использования тайлохранилища, а второй все равно добавлять потом, после того как сделать простое отстреливаение по таймауту. И все это ради пары секунд после 5 минутного перекура? Зачем? Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд?

(0011492) zed (manager) 03-06-2013 11:12	>И первый из этих двух Вообще-то у меня есть свой вариант - сделать ленивое создание и соответствующее удаление хранилища целиком. У нас хранилище сидит в TMapType и все обращения к нему идут через карту. Так вот именно тут, мы можем легко управлять временем жизни хранилища, не создавать его при создании карты, а только по запросу, удалять исходя из активность карты (не кэша) и тому подобное. Причём, польза будет не только для Беркли. >Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд? Просто я не хочу лагов даже в секунду.

(0011493) vdemidov (manager) 03-06-2013 11:38	>У нас хранилище сидит в TMapType и все обращения к нему идут через карту. Так вот именно тут, мы можем легко управлять временем жизни хранилища, не создавать его при создании карты, а только по запросу, удалять исходя из активность карты (не кэша) и тому подобное. Но карта тоже не знает и знать не должна активна ли она сейчас в пользовательском интерфейсе, поэтому опять приходим к тем двум вариантам, которые я уже озувучил. >Просто я не хочу лагов даже в секунду. Тебе жалко пары секунд после пятиминутной паузы? Да экран дольше включается после скринсейвера. Давай поспорим, что никто разницы не заметит?

(0011494) vasketsov (manager) 03-06-2013 11:56	>Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд? Ну вообще говоря да, коннект к СУБД может быть и пару секунд и больше, а потом работа быстрая, зависит от особенностей работы и настройки (например, пока нет в кэше DSN или ARP будет дольше на разрешение соответствующего адреса). >Что за Sync и что за Payload? Sync - проца в тайлохранилище. Payload - буквально - полезная нагрузка (параметр). В простейшем случае Boolean. В более сложном - IInterface и прочие извращения. >второй все равно добавлять потом Ну собственно да, поэтому я и предложил Sync по активным картам и слоям. Фабрика SyncPayload может генерить Payload на основании в том числе информации об активных картах. Программной опцией на неё можно влиять, генерить ей всегда False, или же True если карта активна (если тип будет Boolean, сюда же можно и время вырубания даже активной карты пропихнуть). Соответственно в хранилище этот Payload воспринимается как запрет вырубать карту (ну или с точностью до наоборот). Логика чуть более чем тривиальная, кодится тоже несложно.

(0011495) vdemidov (manager) 03-06-2013 14:48	>Ну собственно да, поэтому я и предложил Sync по активным картам и слоям. > Фабрика SyncPayload может генерить Payload на основании в том числе информации об активных картах. Программной опцией на неё можно влиять, генерить ей всегда False, или же True если карта активна (если тип будет Boolean, сюда же можно и время вырубания даже активной карты пропихнуть). Соответственно в хранилище этот Payload воспринимается как запрет вырубать карту (ну или с точностью до наоборот). Логика чуть более чем тривиальная, кодится тоже несложно. Ну в общем, я тоже склоняюсь к варианту с пинговалкой. А он вполне себе ортогонален к реализации данной хотелки.

(0011625) zed (manager) 10-06-2013 17:47 edited on: 10-06-2013 17:50	Сейчас будет логика такая: каждые 5 минут или каждые 1000 коммитов (операции Write и Delete) будет выполняться проверка TTL файлов БД. Если к БД обращались более 1 минуты назад (тот самый TTL), она считается не нужной и закрывается. Если все БД оказались не нужными и закрылись, то тут же закрывается и env. Если хотя бы одна БД ещё живая - ждём ещё 5 мин или 1000 коммитов и проверяем опять. И что ещё важно, при каждой такой синхронизации инициализируется сброс данных из лога транзакций в БД (поэтому синхронизация и завязана дополнительно на коммиты). При активной записи в кэш, через тот же Менеджер кэша, если не мониторить коммиты, то логи распухают моментально до сотен мегобайт. Посмотрим, как кэш будет вести себя в таком режиме, и если что, озаботимся пинговалгой, чтобы env у активной карты не умирал.

(0011629) Parasite (administrator) 11-06-2013 02:40 edited on: 11-06-2013 02:40	>Если к БД обращались более 1 минуты назад (тот самый TTL), она считается не нужной и закрывается. Имхо, 1 минута - весьма мало. Будет постоянно переоткрываться\перезакрываться даже если юзер просто внимательно на экране что-то рассматривает - или, например, ставит новую метку... Предлагаю 3 или даже 5 минут, и сразу с env (ниже). >Если все БД оказались не нужными и закрылись, то тут же закрывается и env. А разве env у нас не отдельный к каждой карте? Зачем ждать закрытия всех карт - для закрытия конкретного env?

(0011632) vdemidov (manager) 11-06-2013 07:12	> Предлагаю 3 или даже 5 минут, и сразу с env (ниже). Мне тоже кажется, что 1 минута маловато, а то что этот период гораздо меньше периода проверки вобще сделает его слегка непредсказуемым. Может наоборот, проверять раз в минуту, а время жизни минут 5 поставить? >А разве env у нас не отдельный к каждой карте? Зачем ждать закрытия всех карт - для закрытия конкретного env? При чем тут все карты, речь про закрытие всех баз одной карты.

(0011633) Parasite (administrator) 11-06-2013 07:23	>При чем тут все карты, речь про закрытие всех баз одной карты. Фразу "Если все БД оказались не нужными и закрылись, то тут же закрывается и env" я понял в ключе "ВООБЩЕ ВСЕ БД". Если имелась ввиду только одна карта - то ОК.

(0011635) zed (manager) 11-06-2013 08:34	Вообще, я хочу вынести все эти интервалы в конфиг, вместе с настройкой ReadOnly доступа (см. 0001874), тогда можно будет экспериментировать и подбирать оптимальные значения при желании. >Имхо, 1 минута - весьма мало. А там так и было. Фраза "Сейчас будет логика такая" не обязательно означает, что до этого логика была какая-то принципиально другая. По сути, всё что я добавил - закрытие env, если закрыты все БД (данной карты). А интервалы синхронизации я не трогал. >Может наоборот, проверять раз в минуту, а время жизни минут 5 поставить? Не, синхронизация ж кроме всего прочего инициализирует сброс кэша. А минута это довольно часто. Хотя, если часто сбрасывать кэш, то и операция эта будет достаточно быстрой, ввиду малого объёма закэшированных данных. Ситуация с частым закрытием/открытием БД сглаживается тем, что у нас ещё есть кэш в env. Так что, теоретически (хотя, может я и ошибаюсь), файл БД может быть ещё не закрыт, даже если из САСа мы вдруг отключились от этой БД. Но с уверенностью могу сказать, что даже если файл БД закрывается и из env, в кэше всё равно остаются страницы из того файла, вплоть до закрытия/открытия самого env. Исходя из этого, я и озаботился увеличением кэша env через DB_CONFIG

(0011636) Parasite (administrator) 11-06-2013 08:41	>>Имхо, 1 минута - весьма мало. >А там так и было. Фраза "Сейчас будет логика такая" не обязательно означает, что до этого логика была какая-то принципиально другая. Как показывает практика, "до этого" (то есть - вот прямо сейчас) при крэше САСа файлы БД бились даже у той карты, отключение от которой было (на момент крэша) довольно давно. Скажем - час. Если бы оно [сейчас] закрывалось через минуту - при крэше через час бился бы только env. Я неправ? >я хочу вынести все эти интервалы в конфиг Это было бы идеальным.

(0011638) zed (manager) 11-06-2013 08:57	>Если бы оно [сейчас] закрывалось через минуту - при крэше через час бился бы только env. Я неправ? В кэше Беркли, env - всему голова. И эта "голова" сидит в RAM и по возможности держит там страницы когда-либо открываемых БД. В том числе держит и изменения этих страниц, и в зависимости от настроек, закрывая БД из САС нет гарантии, что все изменения тут же залетят в БД. Оно может там всё так же висеть в RAM до второго пришествия. Поэтому при крэше env, может всё полететь к чертям. Вот тут я постарался подробно расписать настройки env, которые могут влиять на то, с какой скоростью всё может полететь к чертям, при крэше чего-либо.

(0011639) Parasite (administrator) 11-06-2013 09:20	>Оно может там всё так же висеть в RAM до второго пришествия. Поэтому при крэше env, может всё полететь к чертям. Вот именно поэтому я и предлагаю закрывать беркли вместе с env через 3..5 мин, а не ступенчато (сперва - файлы, а потом - env). Ибо если оно скрэшится на этом промежутке - еррор все равно будет (env не закрыт) независимо от того, закрыты были уже файлы к тому времени или нет. В общем - ждем реализации, а там тайминги уже оттюним как надо.

(0011640) zed (manager) 11-06-2013 09:25	>В общем - ждем реализации Так реализовано уже. Через 5 минут бездействия, гарантированно закрываются все БД и env.

(0011641) Parasite (administrator) 11-06-2013 09:30	>Так реализовано уже. В сегодняшней ночнушке? ОК, будем покачать и попробовать. :)

(0011664) zed (manager) 14-06-2013 12:20	В завтрашней ночнушке можно будет пробовать изменять интервалы синхронизации через ini файл: http://sasgis.org/mantis/view.php?id=1874#c11663

(0011675) Parasite (administrator) 17-06-2013 04:56	>Через 5 минут бездействия, гарантированно закрываются все БД и env. Вроде работает так как надо. При "просыпании" карты - наблюдается предсказуемый, но вполне терпимый лаг ~1сек. Спасибо.

Users who viewed this issue
User List	Anonymous (4393x)
Total Views	4393
Last View	21-11-2024 09:38

Issue History
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	View Revisions
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	View Revisions
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	View Revisions
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	View Revisions
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	View Revisions
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	=> 24xxxx
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	View Revisions
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	View Revisions
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	View Revisions
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	24xxxx => 131111

Relationships

SASGIS