madf

Стабильная версия на сайте stg.dp.ua. А почему не переносит? Что говорит?

Ну опции RemoveBak и ReadBak модуля store_files никто не отменял. Хотя в определенных случаях и они могут слажать. Никак не доходят руки сделать по нормальному. К стати, каким бы троллем не был vop, но по этому вопросу он совершенно прав. По поводу релиза. У вас есть возможность ускорить его. Людей как всегда не хватает. Так что если есть опыт в программировании - можно подключиться к разработке sgconf_xml погляжу. Но думаю что после релиза он будет больше не нужен

Частично

Не судите строго... видимо я до конца не понимаю что где смотреть. смотрю свойства таблицы charset set cp1251 на сколько я понимаю конвертер переносит данные в базу при помощи стандартного клиента установленого в системе. в качестве просмоторшика я пользуюсь менеджером но какаую бы я не ставил в не кодировку все равно получаю кракозябры. Кстати при помощи стандартного клиента системы тот же ефект. Я так понимаю что конвертер создает таблицы сам, соответсвенно и задает кодировку таблицы но тогда перенося данные из кои8 он должен был их переконвертировать в ср1251. И второй вопрос: конфигуратор получая данные из этой базы в какой кодировке должен их получать?(имею ввиду если данные раньше лежали в кои8 а в базу они переносятся как ср1251 не возникнет ли проблем у конфигуратора их чтением) Если можно разжуйте поподробней я еще учусь. Для самого Stargazer'а все по идее должно быть нормально. А вот при доступе к базе другими средствами (клиентом там, или еще как) нужно будет учитывать те особенности о которых я говорил в соседнем топике.

не з днепропетровска Ха! В одном городе живем

Конвертор переносит базу используя существующие плагины. Клиент не используется. Внутри самого Stargazer'а данные содержатся в кодировке koi8, кроме текстов сообщений пользователям. Сообщения хранятся в кодировке CP1251. Модуль MySQL сам создает нужные таблицы. При этом кодировка явно не указывается, по этому используется та которая установлена для базы. При коннекте к базе не указывается и клиентская кодировка, по этому используется та-же, что и при создании. Т.е. CP1251. При этом туда заносятся данные в кодировке KOI8. Естественно при просмотре получаются кракозябры. Тексты сообщений выглядят нормально потому что для них кодировка совпадает. А в терминале, видимо, установлена KOI8, по этому в логе конвертора они нечитаемы. Не смотря на все эти ужасы, я думаю, все должно работать нормально.

Проще выложить текущий срез исходников. Если надо - могу заслать на почту.

О такой проблеме известно и она уже решена. Ждите релиза.

Не совпадает кодировка базы, client encoding и в том месте где ты просматриваешь таблицы. Попробуй все поставить в koi8-r. Нет проблемма не в client encoding покрайней мере при просмотре. так как он возникает уже при переносе. может кто знает как с этим бороться повторюсь: но что интересно что таблица messages тоже имеет руский текст, а перенеслась нормально А я не только про client encoding написал. Там минимум 3 места где кодировка задается. Короче так: - внутренняя кодировка Stargazer KOI8; - сообщения хранятся в CP1251. Дальше смотри какая у тебя кодировка базы, client encoding и того места откуда смотришь.

Версия, как я вижу, не релизная... Случайно не в отладочном режиме собранная?

Странно как-то... А что в этот момент в /var/log/stargazer.log, /var/log/messages, dmesg?

Не хочет коннектиться - это как?

Проблемы с сетью, например.

Ну вот он как-бы пытается принять заголовок пакета от конфигуратора и никак не может его принять.

А еще можно собрать с отладочной информацией и когда он перестанет коннектится подцепиться к нему gdb: $ gdb /path/to/stargazer (gdb) attach pid-of-stargazer и после этого посмотреть трассы стека по всем потокам: (gdb) thread apply all bt Можно даже выслать мне их на почту: faust@stg.dp.ua

Ну можно попытаться в тупую - наставить журналирования в плагин и посмотреть в каком месте оно затыкается. А потом определить причину.

если не хотите свое сделать, может быть добавите в релиз разработку человека ? Думаю не один из пользователей стг не откажется от данной функии... Я не говорил что не хочу своего делать. Просто на все не хватает рук. А вот добавлять в релиз костыли я точно не буду. Уж извините.

А можно просто добавить в пакет протокола поле "тариф" и передавать его явно, без танцев с бубном И не забыть при этом апнуть версию протокола и диспетчеризовать ее отдельно

Жесть

Каким макаром тарифный план определяется?

В авторизаторі? Думаю нічого. Буду просувати qia.

Мой "хинт" перестает работать, когда начинается новый месяц . Вот другой фикс в конфигураторе, вроде как 3 месяца без глюков http://depositfiles.com/ru/files/i70bbmh2g, при этом в сервере можно всё вернуть обратно. Ну там на самом деле проблема на стороне плагина. Точнее даже на стороне самого Stargazer'а Может это и проблема, но у меня получилось, что не проблема, а на оборот. Использовал эту фичу с обновлением по другому, теперь любые изменения аккаунтов в таблице обновлятся сразу после изменения, нет необходимости давить кнопку refresh. Очень кстати удобно. Ну это тоже правильно. Правда возможна ситуация когда конфигуратор будет показывать одно, а на деле в самом Stargazer'е будет что-то другое Хотя такое возможно только если при внесении изменений произойдет ошибка но конфигуратору уйдет ответ что все ок.

Такое могло случиться если Stargazer был собран через build/make а для sgconf был просто вызван make. При этом новая версия libsrvconf.so просто не собралась и, естественно, не установилась. Stargazer был собран через 1. > ./build 2. > make install sgconf был собран через ./build библиотека скомпилилась кстати, но не была обновлена. я ее просто скопировал взамен старой. теперь проблем нет. Ну да, если запускается из каталога сборки нужно указывать LD_LIBRARY_PATH=../../lib чтобы он брал библиотеки не из /usr/lib

и сколько стартует СТГ на ней времени? у меня получилось: 2010-03-06 04:03:47 -- Storage plugin: postgresql_store v.1.2. Loading successfull. 2010-03-06 04:05:48 -- Users started successfully. после 10ти дней работы, вообще один процесс postgres залочил таблицу stat-ов. попытался остановить СТГ в логах : ну убил все, слил дамп, пересоздал базу с нуля. Время старта плагина уменьшилось до 2х сек. вот теперь сижу и думаю, как будет корректней проапгрейдиться? А то такими глюками, как-то в "продакшн" не хочется лезть... и Вообще "оно" себя чувствует под нагрузкой? Сколько стартует уже не помню, аптайм 147 дней. Если залочить таблицу (например VACUUM FULL) Stargazer не сможет в нее ничего писать. Но будет продолжать нормально работать. И после того как таблица разлочится он все необходимое в нее запишет. Нагрузка в этом сегменте небольшая, всего 200 онлайнеров в пике. По этому Stargazer "кушает" около 7% проца, а PostgreSQL либо в нулях либо около 14% в зависимости от того что там происходит. Для быстрого доступа к данным добавил индексы на fk_user и from_time в таблицу tb_detail_stat. База такая накопилась с сентября (или августа) прошлого года.

Мой "хинт" перестает работать, когда начинается новый месяц . Вот другой фикс в конфигураторе, вроде как 3 месяца без глюков http://depositfiles.com/ru/files/i70bbmh2g, при этом в сервере можно всё вернуть обратно. Ну там на самом деле проблема на стороне плагина. Точнее даже на стороне самого Stargazer'а