0001721: Крушение при конвертации кэша в БД

Notes
(0010094) vdemidov (manager) 30-11-2012 20:17 edited on: 30-11-2012 20:17	Судя по всему вы не выбрали тип файлов в исходном хранилище, точнее неправильно введено расширение.

(0010099) Papazol (reporter) 01-12-2012 08:00 edited on: 01-12-2012 08:14	Ну вроде как правильно выбрал расширение. Однако решил проверить, что у меня в кэше. И оказалось, что в папках с z9 по z14 имеются файлы .png. Откуда они взялись - вопрос не суть, но. Получается, что если в кэш затесался хотя бы один "не такой" файл, процесс может прерваться на самом интересном месте? Хорошо, у меня сразу попался .png, ничего не успело начаться даже. И где искать этот "не такой"? Нельзя просто игнорировать файлы с несовпадающим расширением? Добавлено Удалил указанные папки с мусором. Так всё равно то же самое происходит. Указал вообще одну маленькую папку, там точно только *.jpg, не работает.

(0010100) vdemidov (manager) 01-12-2012 08:12	Нет. Оно свалилось еще до начала любых операций после того как не нашло такого зарегистрированного в программе расширения. А файлы с другим расширением оно просто не заметило бы. Все вопросы по этому конвертеру к Zed.

(0010101) Papazol (reporter) 01-12-2012 08:17 edited on: 01-12-2012 09:38	Да, вопросы к zed. Надо, понимаешь, срочно конвертнуть, а тут вон чаго. Самое интересное - релиз от 10 октября работает нормально с тем же кэшем.

(0010102) vasketsov (manager) 01-12-2012 11:06	Дружище, это сработала проверка на _входе_ в файловое хранилище что не определился первичный тип файла (contenttype). Ни до какого конкретного тайла (файла), ни тем более до его чтения, ни уж тем более до СУБД дело даже не дошло. Так что вполне очевидно, что чистка "мусора" ничего не дала. Попробуй jpeg указать а не jpg.

(0010103) Papazol (reporter) 01-12-2012 11:34 edited on: 01-12-2012 11:37	Во-первых, jpeg - это неправильно, если речь о расширении файлов, а поле названо именно так. И если действительно нужно там писАть jpeg, то это ваще круто! Во-вторых, я уже сконвертировал этот кэш с помощью релиза, всё прошло OK. Все параметры, устанавливаемые в окошке, абсолютно такие же, в том числе и jpg. Вообще-то надо бы подробно описать весь процесс, а то я, например, конвертировал всего два раза, и в обоих случаях были какие-то проблемы. Кстати, jpeg не помогает, и даже png, не имеющий разночтений, всё равно не конвертируется. Да, а что, разве у всех остальных в последней ночнушке это нормально работает?

(0010104) vdemidov (manager) 01-12-2012 11:49	>Да, а что, разве у всех остальных в последней ночнушке это нормально работает? Не знаю. Просто, вероятно, им никто больше не пользуется. Я этого окошка даже не видел ни разу в живую. Только разок в дизайнере открывал.

(0010106) Fetser (reporter) 01-12-2012 12:27	>Просто, вероятно, им никто больше не пользуется. Пользуюсь регулярно, но конечно не каждый день. Последний раз конвертил 13 ноября и тогда всё сработало без вопросов. Точно какая версия программы была трудно проверить но обычно стоит ночнушка, ну максимум двух дневной давности. Сейчас проверил релиз работает, ночнушка за 19 ноября уже не работает как и все последующие. Более ранних версий увы не сохранилось.

(0010107) zed (manager) 01-12-2012 13:45	vdemidov >Все вопросы по этому конвертеру к Zed Вот только не нужно переводить стрелки. Да, этот конвертер делал я, но затем, ты провёл там типа рефакторинг и сломал его. Причём, очевидно, что после рефакторинга ты даже и не пробовал запускать этот конвертер, потому что валится он стабильно и БД тут совершенно ни при чём. Баг исправил, но ночнушку придётся долго ждать, у меня пока что сильно ограничен доступ к интернету. P.S. А раширение можно указывать в различных вариантах: "*.jpg" или ".jpg" или просто "jpg"

(0010108) vdemidov (manager) 01-12-2012 14:03	>Причём, очевидно, что после рефакторинга ты даже и не пробовал запускать этот конвертер Конечно не пробовал. Точно так же я не проверяю еще сотню других разных функций. Я уже писал, что я вообще ни разу не запускал ибо он мне не нужен. С моей точки зрения не самый необходимый функционал. А проверяю я самый базовый. Я бы на твоем месте вообще задал расширение не полем ввода, а комбобоксом, все равно оно непредусмотренные расширения не воспримет. А еще я бы сделал выбор исходного и результирующего хранилищ двумя вариантами, или из списка zmp и тогда дополнительно ничего больше выбирать не нужно, или постороннее хранилище и тогда нужно задавать кучу параметров. Но еще раз повторяю, что мне этот функционал не нужен и переделывать я его не собираюсь.

(0010109) vasketsov (manager) 01-12-2012 14:42	>у всех остальных в последней ночнушке это нормально работает? Я в БД копировал кэш не через конвертер, а через "операции-скопировать", с указанием версии. После реализации копирования в БД оно работает. EXE-ха есть в доработке про СУБД. >я бы сделал выбор исходного и результирующего хранилищ двумя вариантами Вообще говоря да. И "операции-скопировать" в принципе тоже. Вводить руками то что уже и так есть в zmp - потенциально багоопасно.

(0010110) Papazol (reporter) 01-12-2012 15:05	Есть ли вообще смысл иметь данную процедуру в двух местах одновременно? Может, оставить одно что-то, скорей всего в копировании как в более общем варианте?

(0010112) vasketsov (manager) 01-12-2012 19:01	>смысл иметь данную процедуру в двух местах одновременно? Это разные процедуры. См. 5 параграф описания хотелки 1709.

(0010115) Papazol (reporter) 02-12-2012 08:40	Хотелка 1709 чуть о другом, причём так сходу понять, о чём именно, весьма трудно. В отношении данного вопроса я понял, что различия упомянутых процедур в том, что одна из них обрабатывает весь кэш, а другая - только выделенную область. Выделенной областью может быть в том числе и весь кэш, поэтому процедура копирования может полностью охватить все случаи. Это может быть неудобно из-за необходимости выделять "весь мир", но работать-то это будет. Можно даже внести в интерфейс опцию "Выделить всё", и тогда вообще без проблем. Так понял я, а как на самом деле?

(0010116) Fetser (reporter) 02-12-2012 10:36	Я так понимаю, что разница в том что изначально пытается программа конвертить. В случае копирования программа ищет все файлы в области и если их нет то тратит время на проверку и поиск тайлов которых нет в кэше. А менеджере кэша она не проверяет отсутствующие тайлы, а конвертит те что есть в кэше, без проверки отсутствующих.

(0010117) vasketsov (manager) 02-12-2012 17:39	>но работать-то это будет Как быстрее скопировать папку z18, в проводнике руками, или выделив весь сир и копируя выделенную область? Понятно почему? Так вот менеджер кэша по идее копирует как проводник СОДЕРЖИМОЕ, а не перечисляя все тайлы.

(0010118) Papazol (reporter) 02-12-2012 19:59	Ладно, согласен оставить оба варианта:) Но проверять работоспособность придётся у обоих. Кстати, подумалось: а есть смысл конвертировать выделенную область в БД? Как применять это? Это оффтоп, пока новую ночнушку ждём.

(0010119) Dima2000 (developer) 02-12-2012 20:30	>а есть смысл конвертировать выделенную область в БД? Как применять это? Смысл есть, например перенести на другую машину не весь многогигабайтный кэш, а лишь нужную область. >Как быстрее скопировать папку z18, в проводнике руками, или выделив весь сир и копируя выделенную область? Понятно почему? Кстати, если сделать новый итератор для задач перебора лишь существующих тайлов (что применимо к экспорту, копированию, удалению, даже построению карты заполнения), то можно приблизить скорость перебора к скорости менеджера кэша. Итератор при этом должен идти по папкам кэша в ограничивающем прямоугольнике и проверять найденные файлы на попадание в полигон и лишь тогда выдавать их на выход. Для оптимизации можно для каждого Х (и каждого Y/1024) сначала построить внутри список существующих файлов, проверить его на попадание в полигон, и потом выдать в сортированном по Y виде. Тогда вообще "выхлоп" будет аналогичен существующему итератору, только во много раз быстрее. Во всяком случае для дефолтного файлового кэша. Для БД не уверен.

(0010124) DJ VK (manager) 03-12-2012 16:22 edited on: 03-12-2012 19:38	>>Сейчас проверил релиз работает, ночнушка за 19 ноября уже не работает как и все последующие. Релиз и последующие ночнушки (недели 2 давности может) у меня работают нормально. но системный кэш растет и через некоторое время съедает всю(!) свободную озу. Она не съедается вся, но конкретно занята и все тормозит. Но это не винда глючит, а планета какими-то скрытыми механизмами винду притормаживает. По закрытию планеты ОЗУ вновь восстанавливается, приходится скачав несколько полигонов :-((( перезапускать программу. Работает после этого шустро. Скачивается сразу в Беркли, думаю дело в этом... Может только xp64 такая глючная?

(0010126) vdemidov (manager) 03-12-2012 19:48	А в чем вопрос то? Растет системный кэш так как идет работа с кучей файлов. А в случае берклидб это далеко немелкие файлы.

Users who viewed this issue
User List	Anonymous (3128x)
Total Views	3128
Last View	21-11-2024 16:20

Issue History
Date Modified	Username	Field	Change
30-11-2012 20:05	Papazol	New Issue
30-11-2012 20:05	Papazol	File Added: SASPlanet.Debug.elf
30-11-2012 20:17	vdemidov	Note Added: 0010094
30-11-2012 20:17	vdemidov	Note Edited: 0010094	View Revisions
01-12-2012 08:00	Papazol	Note Added: 0010099
01-12-2012 08:01	Papazol	Note Edited: 0010099	View Revisions
01-12-2012 08:12	vdemidov	Note Added: 0010100
01-12-2012 08:14	Papazol	Note Edited: 0010099	View Revisions
01-12-2012 08:17	Papazol	Note Added: 0010101
01-12-2012 09:38	Papazol	Note Edited: 0010101	View Revisions
01-12-2012 11:06	vasketsov	Note Added: 0010102
01-12-2012 11:34	Papazol	Note Added: 0010103
01-12-2012 11:36	Papazol	Note Edited: 0010103	View Revisions
01-12-2012 11:37	Papazol	Note Edited: 0010103	View Revisions
01-12-2012 11:49	vdemidov	Note Added: 0010104
01-12-2012 12:27	Fetser	Note Added: 0010106
01-12-2012 13:45	zed	Note Added: 0010107
01-12-2012 14:03	vdemidov	Note Added: 0010108
01-12-2012 14:42	vasketsov	Note Added: 0010109
01-12-2012 15:05	Papazol	Note Added: 0010110
01-12-2012 19:01	vasketsov	Note Added: 0010112
02-12-2012 08:40	Papazol	Note Added: 0010115
02-12-2012 10:36	Fetser	Note Added: 0010116
02-12-2012 17:39	vasketsov	Note Added: 0010117
02-12-2012 19:59	Papazol	Note Added: 0010118
02-12-2012 20:30	Dima2000	Note Added: 0010119
03-12-2012 16:22	DJ VK	Note Added: 0010124
03-12-2012 16:27	DJ VK	Sticky Issue	No => Yes
03-12-2012 16:27	DJ VK	File Added: sasmem.jpg
03-12-2012 19:38	DJ VK	Note Edited: 0010124	View Revisions
03-12-2012 19:48	vdemidov	Note Added: 0010126
04-12-2012 06:39	vdemidov	Sticky Issue	Yes => No
05-12-2012 13:01	vdemidov	Status	new => resolved
05-12-2012 13:01	vdemidov	Fixed in Version	=> 131111
05-12-2012 13:01	vdemidov	Resolution	open => fixed
05-12-2012 13:01	vdemidov	Assigned To	=> zed
05-12-2012 13:01	vdemidov	Target Version	=> 131111

Relationships

SASGIS