Форум » LetoDB, HbNetio. » Leto DB Server (продолжение) » Ответить
Leto DB Server (продолжение)
alkresin: Только что открыл на Sourceforge новый проект - Leto DB Server - https://sourceforge.net/projects/letodb Это мультиплатформенный ( Windows, Unix/Linux ) сервер баз данных, предоставляющий клиентским программам доступ к dbf/cdx файлам, находящимся на удаленном сервере ( можно и на локальном компьютере запускать - в отладочных целях ). В общем, как ADS :). Проект - на стадии разработки, не все даже базовые функции еще реализованы, до оптимизации дело еще не дошло. Но работает :). Крутится у меня на сервере несколько дней, подключал до 15 клиентов, пока не падает. Мои программы работают с ним нормально. Преимущества по сравнению с обычным файл-сервером: 1) Безопасность - базы могут быть в каталоге, недоступном для клиентских компьютеров - никто их случайно не удалит и не повредит. 2) Поскольку базы открываются серверной программой, а не клиентской, ее целостности ничего не грозит при случайном отключении клиентского компьютера. 3) значительное уменьшение сетевого траффика. 4) Должен быть, по идее, выигрыш в скорости. 5) Возможность контроля за пользователями с помощью утилиты manage ( можно придумать и другие формы контроля ). 6) Можно будет сделать транзакции, stored procedures на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
alkresin: В присланном вами test.dbf есть "нехорошая запись" ( recno() = 61 ) с несимвольной информацией - похоже, битая. После индексирования она становится 1-й и при Gotop() на нее получается ошибка - этим объясняется, почему с descending все работает ( первой становится другая запись ). После удаления этой записи и упаковки все работает нормально. Это, впрочем, не отменяет того факта, что ошибка возвращаться не должна - надо смотреть, в чем дело.
alkresin: Исправил я это дело, проблема была в битом поле типа DATE. Кстати, Александр, начал я смотреть ваши изменения - что-то вы в common_c.c форматирование сбили, там теперь разделитель строк не r\n, а \r\r\n
alx_on: alkresin пишет: разделитель строк не r\n, а \r\r\n Знаю :) я уже пытался выложить изменения, но меня опередили и теперь опять синхронизирую уффф, выложил проверьте плз
alkresin: уффф, выложил проверьте плз С common_c.c все в порядке.
alx_on: alkresin пишет: Исправил я это дело, проблема была в битом поле типа DATE. Может быть более жесткую проверку сделать (только цифры)? Может возникнуть аналогичная ситуация, но символ будет, например, больше пробела
alkresin: Может быть более жесткую проверку сделать (только цифры)? Может возникнуть аналогичная ситуация, но символ будет, например, больше пробела Нет особой необходимости. Вообще говоря, там достаточно было добавить проверку на \0, беда была именно в этом. Сервер передавал 8 нулей из битой записи, а клиент, а ведь \0 в первом байте - признак пустого поля. Клиент, обнаружив его, начинал читать следующее поля со следующего байта - и запутался.
santy: после изменений в файле funcleto.h #define hb_cdp_page hb_cdppage() #if defined(HB_ERRCODE) typedef HB_ERRCODE ERRCODE; #endif не компилится в xHarbour (121_6714) если вернуть назад, всё нормально проходит перед этим была одна ошибка в препроцесоре в файле server.prg, она и осталась, причина ошибки пока непонятна.
alkresin: Александр, после последних изменений появилась проблема ( с 2010-06-01 16:45 UTC+0300 Alexander Kresin ) работает нормально, я сейчас проверил. См. сообщение на letodb-developers@lists.sourceforge.net: In test_ta.prg i add dbskip() ... AddNakl( 1, Date(), { 1400.5, 28632.28, 800.51 } ) AddNakl( 2, Date(), { 58003, 930.5 } ) ? "Records has been added" dbskip() ... and get Error LETO/1000 Data type error ... and letodb_crash.log Сервер падает. Где-то у вас ошибка закралась...
alkresin: И еще вопрос по изменениям в протоколе: он изменился только для файлов с количеством полей > 256, или для всех ? Т.е., могу ли я компилировать приложения с новой версией, не трогая сервер ( у меня нет файлов с таким большим количеством полей ) ?
alx_on: alkresin пишет: могу ли я компилировать приложения с новой версией Да. Фактически это не изменение, а исправление Ошибку с DbSkip() поправил (тупо else пропустил как то )
alkresin: А на CVS исправления еще не запостили ?
alx_on: alkresin пишет: А на CVS исправления еще не запостили ? Выложил У меня все равно где то падает собака! Поймать не могу (переход на harbour 1.01 для меня - -как совсем крайний случай :) )
alkresin: Так а падает на harbour 1.01 или не проверяли ? Я согласен, что откат на старую версию - не выход, но такая проверка может подтолкнуть в правильном направлении. P.S. Падает и без установленных MSVS Redistributable ?
alx_on: alkresin пишет: Так а падает на harbour 1.01 или не проверяли ? Пока руки не дошли P.S. Падает и без установленных MSVS Redistributable ? Скорее всего молча пропускает ошибки Потому как с MSVS Redistributable отладчик (gdb) показывает ошибку примерно такого плана: неверный вызов (или неверные параметры вызова, точно не помню) С-функций (или библиотечных) Т.е. более жесткая проверка параметров вызова стандартных библиотечных функций
alx_on: Проявляется при интенсивной нагрузке с одной машины (3 задачи с обработкой больших файлов, десятки тысяч записей) Два падение на win-сервере 1. (gdb) bt #0 0x0041cb21 in dlmalloc () #1 0x0028670c in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Dump of assembler code for function dlmalloc: 0x0041cab0 <+0>: push %ebp 0x0041cab1 <+1>: push %edi 0x0041cab2 <+2>: push %esi 0x0041cab3 <+3>: push %ebx 0x0041cab4 <+4>: sub $0x7c,%esp 0x0041cab7 <+7>: mov 0x90(%esp),%ebx 0x0041cabe <+14>: cmp $0xf4,%ebx 0x0041cac4 <+20>: ja 0x41cb40 <dlmalloc+144> 0x0041cac6 <+22>: cmp $0xa,%ebx 0x0041cac9 <+25>: ja 0x41cbf0 <dlmalloc+320> 0x0041cacf <+31>: mov 0x527660,%esi 0x0041cad5 <+37>: mov $0x2,%ecx 0x0041cada <+42>: mov $0x2,%edx 0x0041cadf <+47>: mov $0x10,%ebx 0x0041cae4 <+52>: mov %esi,%eax 0x0041cae6 <+54>: shr %cl,%eax 0x0041cae8 <+56>: test $0x3,%al 0x0041caea <+58>: je 0x41cc0f <dlmalloc+351> 0x0041caf0 <+64>: and $0x1,%eax 0x0041caf3 <+67>: xor $0x1,%eax 0x0041caf6 <+70>: lea (%eax,%edx,1),%edx 0x0041caf9 <+73>: mov %edx,%ebx 0x0041cafb <+75>: shl $0x4,%ebx 0x0041cafe <+78>: add $0x527688,%ebx 0x0041cb04 <+84>: mov 0x8(%ebx),%eax 0x0041cb07 <+87>: mov 0x8(%eax),%edi 0x0041cb0a <+90>: cmp %edi,%ebx 0x0041cb0c <+92>: je 0x41d250 <dlmalloc+1952> 0x0041cb12 <+98>: cmp %edi,0x527670 0x0041cb18 <+104>: ja 0x41d561 <dlmalloc+2737> 0x0041cb1e <+110>: mov %edi,0x8(%ebx) => 0x0041cb21 <+113>: mov %ebx,0xc(%edi) 2. Starting program: D:\letodb.exe [New Thread 912.0x864] [New Thread 912.0x96c] warning: Invalid parameter passed to C runtime function. warning: Invalid parameter passed to C runtime function. Падение на Mac-сервер Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x2019825c 0x0001d231 in hb_ip_rfd_set (hSocket=-1) at ../main/src/letodb/common/hbip.c:894 894 FD_SET( hSocket, &rd_fds ); Конкретно в этом случае incoming = hb_ipAccept( hSocketMain, -1, szBuffer, &lTemp ); вернула -1, что является ошибкой
alx_on: Выложил новые изменения Обработка ошибки сети Решение временное, надо по другому как то реализовать Но как затычка пойдет Проверьте у себя внимательно плз Тестировал интенсивно у себя в течении часа. На последнем harbour с SVN! То что раньше падало, максимум, через 20 минут - не упало! Может совпало с погодой? :) PS да, на предмет целостности данных не сильно смотрел, но вроде не должно это повлиять :)
alkresin: Очень интересно! Здорово, что вы на это вышли, Александр. Пожалуй, hb_ipAccept() стоит немного изменить. Получается, что если accept() завершился с ошибкой ( вернул -1 ), но последующий WSAGetLastError() ( или errno для Линукс ) вернул 0, то все вроде-бы в порядке и для этого -1 вызываются другие функции. А ситуация такая может быть, если между вызовами accept() и WSAGetLastError() вклинился другой thread со своими socket вызовами и библиотека сокетов не thread safe.
alkresin: Я поменял немного hb_ipAccept() в свете того, что писал ранее, надеюсь - будет работать.
Pasha: Поправил баг, связанный с установкой кодовой страницы на сервере. По-видимому, он возник после добавления авторизации пользователей: 6-й и более параметры команды intro просто игнорировались
Pasha: Александр, наверное еще в srvleto.h - USERSTRU надо добавить: USHORT uiVarsOwnCurr;
полная версия страницы