Отправлено: 31.01.08 11:36. Заголовок: Leto DB Server (продолжение)

Только что открыл на 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 на Харборе, ... и вообще все в наших руках :).

Кто хочет участвовать в разработке, тестировании - пишите.

 Отправлено: 31.01.10 16:57. Заголовок: Pasha пишет: Вот ан..

Pasha пишет:

цитата:

Вот аналог DateTime() с миллисекундами:

Ok. Спасибо.

 Отправлено: 02.02.10 18:47. Заголовок: PSP пишет: Кто-нибу..

PSP пишет:

цитата:

Кто-нибудь может проверить, работает ли FLock(): у меня при попытке блокировки с помощью FLock(), она возвращает .T., но не блокирует файл. DBInfo( DBI_ISFLOCK ) возвращает .F. и все операции блокировок/изменения работают.

Пример в студию, пожалуйста.
Я проверял - вроде и dbInfo() правильное значение возвращает, и flock() в параллельном процессе не блокирует файл ...

 Отправлено: 03.02.10 20:27. Заголовок: Код простейший: - пе..

Код простейший:
- первый процесс: FLock() --> .T., DBInfo( DBI_ISFLOCK ) --> .T. (процесс не завершаем).
- второй процесс: FLock() --> .F., DBInfo( DBI_ISFLOCK ) --> .F., RLock() на любой записи --> .T. и спокойно можно писАть.

 Отправлено: 04.02.10 09:19. Заголовок: - первый процесс: FL..

цитата:

- первый процесс: FLock() --> .T., DBInfo( DBI_ISFLOCK ) --> .T. (процесс не завершаем). - второй процесс: FLock() --> .F., DBInfo( DBI_ISFLOCK ) --> .F., RLock() на любой записи --> .T. и спокойно можно писАть.

Ясно. А я только FLock() --> .F., DBInfo( DBI_ISFLOCK ) --> .F. проверил и успокоился :).
Починим.

 Отправлено: 04.02.10 10:32. Заголовок: - первый процесс: FL..

цитата:

- первый процесс: FLock() --> .T., DBInfo( DBI_ISFLOCK ) --> .T. (процесс не завершаем). - второй процесс: FLock() --> .F., DBInfo( DBI_ISFLOCK ) --> .F., RLock() на любой записи --> .T. и спокойно можно писАть.

Проверил еще раз - Rlock() во втором процессе возвращает .f.:

#include "dbinfo.ch"
Function Main
Local cPath := "//127.0.0.1:2812/"

REQUEST LETO
RDDSETDEFAULT( "LETO" )

use ( cpath+"dopsv" ) new shared
? flock()
? dbinfo( DBI_ISFLOCK )
inkey(0)
go top
? rlock()
inkey(0)

return nil

Может, у вас серверная часть старая ?

 Отправлено: 04.02.10 11:03. Заголовок: Ну что ж... плохо бы..

Ну что ж... плохо быть тупым...
Все работает. Посыпаю голову пеплом...
Спасибо, Александр, извините за бескойство.

 Отправлено: 24.03.10 13:13. Заголовок: Привет Взял последн..

Привет

Взял последний harbour
На серверной части SCOPE просто игнорируются (для примера можно взять любую таблицу с индексом и поставить несуществующие скопы, будет бегать по ВСЕЙ таблице)
Я поправил для себя и могу выложить изменения в CVS
Просто интересно - может только у меня такое проявляется? Потому как никаких правок в harbour'е, влияющих на letodb не нашел

 Отправлено: 29.03.10 00:04. Заголовок: Никто не сталкивался..

Никто не сталкивался? Моя особенность?
хм...

 Отправлено: 29.03.10 01:53. Заголовок: alx_on пишет: Никто..

alx_on пишет:

цитата:

Никто не сталкивался?

Давай рабочий пример....

 Отправлено: 29.03.10 11:09. Заголовок: alx_on пишет: Никто..

alx_on пишет:

цитата:

Никто не сталкивался? Моя особенность?

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

 Отправлено: 01.04.10 09:39. Заголовок: Давайте пример. Я са..

Давайте пример. Я сам Scope не пользуюсь. Когда-то проверял, вроде все работало.

 Отправлено: 01.04.10 12:52. Заголовок: В тексте сервера ест..

В тексте сервера есть небольшая ошибка в константах ставится SCOPE TOP и BOTTOM а в конце снимается 2 раза TOP
возможно это ?

 Отправлено: 03.04.10 14:08. Заголовок: goest пишет: Давайт..

alkresin пишет:

цитата:

Давайте пример

Извините за долгий ответ (никак не могу выдрать маленький рабочий пример для повтора ошибки, но в большом проекте лажается)
вот кусок кода (letofunc.c)

static PHB_ITEM leto_KeyToItem( DBFAREAP pArea, const char *ptr, int iKeyLen, const char *szOrder )
{
...
pInfo.itmOrder = NULL;
pInfo.itmResult = hb_itemPutC( NULL, "" );
SELF_ORDINFO( (AREAP)pArea, DBOI_KEYTYPE, &pInfo );
KeyType = *( hb_itemGetCPtr( pInfo.itmResult ) );

если вместо "pInfo.itmOrder = NULL;" поставить "pInfo.itmOrder = hb_itemPutC( NULL, имя ордера );"
то все работает. С чем связано понять пока не могу...

Плюс сейчас тестируем (5-10 тестировщиков на реальной базе) - раз или два в день letodb падает (может быть уже последствия исправления ошибки, указанной выше, очень мало времени на глубокий анализ проблемы, да повторяется не стабильно):

User: 192.168.170.147 TST-NURGALIEVA personal.exe
Command: goto;2049;-1;;A;
Table: \refer\pymnt.dbf
Unrecoverable error 6005: Exception error: %s.

Unrecoverable error 9011:
User: (null) (null) (null)
Command: open;01;6;/personal\data\default\persn___.dbf;PERSN;TF;RU866;
Unrecoverable error 6005: Exception error: %s


goest пишет:

цитата:

В тексте сервера есть небольшая ошибка

а где конкретно?

 Отправлено: 15.04.10 14:26. Заголовок: alx_on пишет: pInfo..

alx_on пишет:

цитата:

pInfo.itmOrder = NULL; pInfo.itmResult = hb_itemPutC( NULL, "" ); SELF_ORDINFO( (AREAP)pArea, DBOI_KEYTYPE, &pInfo ); KeyType = *( hb_itemGetCPtr( pInfo.itmResult ) ); если вместо "pInfo.itmOrder = NULL;" поставить "pInfo.itmOrder = hb_itemPutC( NULL, имя ордера );" то все работает. С чем связано понять пока не могу...

Если ordinfo не получает имя тэга в itmOrder, он использует текущий. Когда leto_KeyToItem вызывается из leto_Seek, все работает правильно, т.к. в leto_Seek предварительно устанавливается текущий тэг ( leto_Setfocus ), а вот в leto_Scope это не происходит, отсюда и неверная работа ordinfo и, соответственно, leto_KeyToItem. Поэтому надо добавить в leto_KeyToItem четвертый параметр - имя ордера и поставить:
if( szOrder ) pInfo.itmOrder = hb_itemPutC( NULL, szOrder );
Из leto_Seek передавать NULL, а из leto_Scope - szOrder.

 Отправлено: 15.04.10 14:56. Заголовок: goest пишет: В текс..

goest пишет:

цитата:

В тексте сервера есть небольшая ошибка в константах ставится SCOPE TOP и BOTTOM а в конце снимается 2 раза TOP

Не нашел я такого места.

 Отправлено: 04.05.10 11:35. Заголовок: На CVS обновился Let..

На CVS обновился LetoDB.
Добавились функции для работы с общими (shared) переменными. Могут быть очень полезны.

цитата:

LETO_VARSET( cGroupName, cVarName, xValue[, nFlags[, @xRetValue]] ) --> lSuccess LETO_VARGET( cGroupName, cVarName ) --> xValue LETO_VARINCR( cGroupName, cVarName ) --> nValue LETO_VARDECR( cGroupName, cVarName ) --> nValue LETO_VARDEL( cGroupName, cVarName ) --> lSuccess LETO_VARGETLIST( [cGroupName] ) --> aList

цитата:

6. Variables management Letodb allows to manage variables, which are shared between applications, connected to the server. Variables are separated into groups and may be of logical, integer or character type. You can set a variable, get it, delete or increment/decrement ( numerical, of course ). All operations on variables are performed consecutively by one thread, so the variables may work as semaphores. See the functions list for a syntax of appropriate functions and tests/test_var.prg for a sample. Letodb.ini may contain lines to determine the maximum number of variables and a maximum size of a text variable.

У меня вопрос к Александру:
если приложение, создавшее какую-либо переменную, аварийно завершается (связь с сервером исчезает),
сервер продолжает хранить эту переменную или уничтожает?

 Отправлено: 04.05.10 11:59. Заголовок: PSP пишет: если при..

PSP пишет:

цитата:

если приложение, создавшее какую-либо переменную, аварийно завершается (связь с сервером исчезает), сервер продолжает хранить эту переменную или уничтожает?

Переменная остается.
Но я собираюсь добавить флаг для leto_Varset(), который определит создаваемую переменную как подлежащую автоматическому удалению после завершения работы создавшего ее приложения.

Сейчас я эти функции использую следующим образом:
у меня есть программы, расположенные на удаленных производственных участках, собирающие информацию с датчиков и складывающие обсчитанные результаты в dbf. На тех же компьютерах стоит letodb и через него в офисе мы получаем эти результаты. А через "shared variables" передается оперативная информация о состоянии датчиков и самой программы.

 Отправлено: 04.05.10 12:08. Заголовок: alkresin пишет: Но ..

alkresin пишет:

цитата:

Но я собираюсь добавить флаг для leto_Varset(), который определит создаваемую переменную как подлежащую автоматическому удалению после завершения работы создавшего ее приложения.

Имхо, нужно.

цитата:

Сейчас я эти функции использую следующим образом: у меня есть программы, расположенные на удаленных производственных участках, собирающие информацию с датчиков и складывающие обсчитанные результаты в dbf. На тех же компьютерах стоит letodb и через него в офисе мы получаем эти результаты. А через "shared variables" передается оперативная информация о состоянии датчиков и самой программы.

Очень полезные функции. Спасибо!

 Отправлено: 19.05.10 00:10. Заголовок: Ошибка при установке SET RELATION

Заметил неприятность
Ошибка обновления буфера записи после SET RELATION
Проявляется, например, так (упрощенно):

use "alias1", "alias2"
ставим ордер ("CODE") на alias1 (ключ "FIELD->CODE", {"CODE","C",6,0})
SELECT alias2
SET RELATION TO alias1->CODE INTO alias1
SELECT alias1
снова ставим ордер ("CODE")
!---
SEEK "000001"
запись найдена, RECNO правильно
чтение любого поля возвращает старое значение (до поиска)
!---

Сделав, например, два раза подряд SEEK снова все хорошо
или сразу после "SET RELATION" прочитав любое поле

Пока не разбирался в чем дело. Завтра (О! сегодня) буду посмотреть. Сбивает с толку то, что лажается в странной ситуации - "папа" никак не учавствует! Т.е. relation вообще не должен влиять

 Отправлено: 21.05.10 12:33. Заголовок: Разобрался с RELATIO..

Разобрался с RELATION
вот пример текущего кода (leto1.c):
Скрытый текст

static ERRCODE letoGoTop( LETOAREAP pArea ) { char sData[32], * ptr; HB_TRACE(HB_TR_DEBUG, ("letoGoTop(%p)", pArea)); if( pArea->uiUpdated ) leto_PutRec( pArea ); sprintf( sData,"goto;%lu;-1;%s;%c;\r\n", pArea->hTable, (pArea->pTagCurrent)? pArea->pTagCurrent->TagName:"", (char)( (hb_setGetDeleted())? 0x41 : 0x40 ) ); if ( !leto_SendRecv( pArea, sData, 0, 1021 ) ) return FAILURE; ptr = leto_firstchar(); leto_ParseRec( pArea, ptr ); pArea->ptrBuf = NULL; SELF_SKIPFILTER( ( AREAP ) pArea, 1 ); if( pArea->area.lpdbRelations ) return SELF_SYNCCHILDREN( ( AREAP ) pArea ); else return SUCCESS; }

после DBGOTOP() на родительской таблице выполнение DBSEEK() на подчиненной лажается (находит не ту запись)
Если сделать так:
Скрытый текст

static ERRCODE letoGoTop( LETOAREAP pArea ) { char sData[32], * ptr; HB_TRACE(HB_TR_DEBUG, ("letoGoTop(%p)", pArea)); sprintf( sData,"letoGoTop(%p)", pArea ); leto_writelog(sData,0); if( pArea->uiUpdated ) leto_PutRec( pArea ); sprintf( sData,"goto;%lu;-1;%s;%c;\r\n", pArea->hTable, (pArea->pTagCurrent)? pArea->pTagCurrent->TagName:"", (char)( (hb_setGetDeleted())? 0x41 : 0x40 ) ); leto_writelog(sData,0); if ( !leto_SendRecv( pArea, sData, 0, 1021 ) ) return FAILURE; ptr = leto_firstchar(); leto_writelog(ptr,0); leto_ParseRec( pArea, ptr ); pArea->ptrBuf = NULL; if( pArea->area.lpdbRelations ) { if( SELF_SYNCCHILDREN( ( AREAP ) pArea ) != SUCCESS ) return FAILURE; } SELF_SKIPFILTER( ( AREAP ) pArea, 1 ); return SUCCESS; }

Т.е. переставить местами SELF_SYNCCHILDREN и SELF_SKIPFILTER, то все работает
Вопрос к alkresin: я правильно понял проблему или это просто так повезло в моем случае?

PS остались моменты, которые еще не смотрел подробно:
1. после DBGOTO(LASTREC()+100) на родительской таблице - на подчиненной должно тоже встать на LASTREC()+1. Этого не происходит (встает на запись, найденную по пустому ключю, в драйвере CDX все ок). Причем именно GOTO, остальные команды перемещения отрабатывают правильно.
2. OrdKeyVal() на записи за пределами таблицы (LASTREC()+1) в драйвере CDX возвращает NIL. LetoDB некую строку (она правильная, но здесь несовместимость со стандартным драйвером CDX)

 Отправлено: 21.05.10 13:40. Заголовок: alx_on пишет: Т.е. ..

alx_on пишет:

цитата:

Т.е. переставить местами SELF_SYNCCHILDREN и SELF_SKIPFILTER, то все работает Вопрос к alkresin: я правильно понял проблему или это просто так повезло в моем случае?

Думаю, что просто повезло.
Чтобы решить проблему, надо во всех операциях перемещения вставить строку

pArea->lpdbPendingRel = NULL;

Дело в том, что когда в родительской области происходит перемещение этот элемент структуры child area устанавливается ( см. letoChildSync ) и когда мы читаем запись из child area, то при установленном pArea->lpdbPendingRel происходит перемещение в child области.

 Отправлено: 21.05.10 14:15. Заголовок: alkresin Примерно ..

alkresin

Примерно так?

Скрытый текст

static ERRCODE letoGoTop( LETOAREAP pArea ) { char sData[32], * ptr; HB_TRACE(HB_TR_DEBUG, ("letoGoTop(%p)", pArea)); if( pArea->uiUpdated ) leto_PutRec( pArea ); sprintf( sData,"goto;%lu;-1;%s;%c;\r\n", pArea->hTable, (pArea->pTagCurrent)? pArea->pTagCurrent->TagName:"", (char)( (hb_setGetDeleted())? 0x41 : 0x40 ) ); if ( !leto_SendRecv( pArea, sData, 0, 1021 ) ) return FAILURE; ptr = leto_firstchar(); leto_ParseRec( pArea, ptr ); pArea->ptrBuf = NULL; SELF_SKIPFILTER( ( AREAP ) pArea, 1 ); if( pArea->area.lpdbRelations ) { if( SELF_SYNCCHILDREN( ( AREAP ) pArea ) != SUCCESS ) return FAILURE; } pArea->lpdbPendingRel = NULL; return SUCCESS; }

PS Вставлять вообще ВЕЗДЕ или только после SELF_SYNCCHILDREN?
PPS Сама функция letoChildSync() не сбрасывает lpdbPendingRel. Ее тоже необходимо поправить?

PPPS Для текущей версии harbour вместо HB_LONG используется HB_MAXINT. У себя я поправил (иначе падало. Например в UpdateRec обработка числовых полей HB_FT_LONG и HB_FT_FLOAT)

 Отправлено: 21.05.10 14:57. Заголовок: Примерно так? Лучш..

цитата:

Примерно так?

Лучше поставить в начале функции.

цитата:

PS Вставлять вообще ВЕЗДЕ или только после SELF_SYNCCHILDREN?

Во всех функциях перемещения. SELF_SYNCCHILDREN тут ни при чем, так как она вызывается для синхронизации детей текущей area.

цитата:

PPS Сама функция letoChildSync() не сбрасывает lpdbPendingRel. Ее тоже необходимо поправить?

Нет, letoChildSync() устанавливает lpdbRelations для себя, ее трогать не надо.

Эта штука (lpdbRelations) обнуляется для того, чтобы area, где она установлена родителем, не перемещала текущую запись в соответствии с положением родителя.

 Отправлено: 25.05.10 10:44. Заголовок: alkresin пишет: Что..

alkresin пишет:

цитата:

Чтобы решить проблему, надо во всех операциях перемещения вставить строку pArea->lpdbPendingRel = NULL;

Выложил сегодня эти изменения на CVS

 Отправлено: 25.05.10 18:25. Заголовок: alkresin Выложил св..

alkresin
Выложил свои изменения (в продолжение темы relations).
1. DBSKIP(0) ничего не делал (в принципе, нормально для родителя, но дитя должно перемещаться).
2. DbAppend() не синхронизировал записи
3. RECNO() возвращал значение до синхронизации с родителем (также блокировка)
Поправлена установка фильтра с национальными символами
Изменил HB_LONG на HB_MAXINT (вопрос: на xHarbour это компиляется?)

 Отправлено: 25.05.10 21:10. Заголовок: alx_on пишет: Измен..

alx_on пишет:

цитата:

Изменил HB_LONG на HB_MAXINT (вопрос: на xHarbour это компиляется?)

Не знаю, как на xHarbour, а на той версии Harbour, которой я пользуюсь, HB_MAXINT не определен ...

 Отправлено: 25.05.10 21:29. Заголовок: Проверил xHarbour - ..

Проверил xHarbour - там тоже HB_MAXINT не определен.

 Отправлено: 25.05.10 21:40. Заголовок: alkresin пишет: Не ..

alkresin пишет:

цитата:

Не знаю, как на xHarbour, а на той версии Harbour, которой я пользуюсь, HB_MAXINT не определен ...

я пользуюсь с SVN
2 варианта
либо нет HB_MAXINT под определенную платформу (так уже было)
либо придется проверять версию (начиная с какой?)

под xHarbour могу поправить (только проверить не смогу)
PS кстати, я запускаю letodb под MacOSX (10.6) - все работает

 Отправлено: 26.05.10 08:02. Заголовок: alx_on пишет: я пол..

alx_on пишет:

цитата:

я пользуюсь с SVN

А я пользуюсь "Changelog 2008-09-17 18:04" :) и в ближайшее время переходить на более новую не планирую.
Давайте вернем это дело назад. Думаю, я не один такой, кто еще не перешел на Harbour-2.

 Отправлено: 26.05.10 08:31. Заголовок: alkresin пишет: Дав..

alkresin пишет:

цитата:

Давайте вернем это дело назад

Может, конечно, это совпадение, но у меня с HB_LONG падает
Обрамим проверками на Harbour-2
По типу:

#if defined (__XHARBOUR__) || !defined(__HARBOUR__) || ( (__HARBOUR__ - 0) < 0x020000 )
HB_LONG lVal
#else
HB_MAXINT lVal
#endif

или так (в самом начале):
#if !defined (HB_MAXINT)
#define HB_MAXINT HB_LONG
#endif
В течение часа выложу

 Отправлено: 26.05.10 09:00. Заголовок: alx_on пишет: #if !..

alx_on пишет:

цитата:

#if !defined (HB_MAXINT) #define HB_MAXINT HB_LONG #endif

Так не получится, потому что HB_MAXINT определен через typedef и defined (HB_MAXINT) всегда будет false.

 Отправлено: 26.05.10 09:03. Заголовок: alkresin пишет: Так..

alkresin пишет:

цитата:

Так не получится, потому

да, я уже заметил :)
значит первый вариант

 Отправлено: 26.05.10 09:28. Заголовок: alkresin выложил..

alkresin
выложил

 Отправлено: 26.05.10 12:41. Заголовок: alx_on пишет: PS кс..

alx_on пишет:

цитата:

PS кстати, я запускаю letodb под MacOSX (10.6) - все работает

Круто ! Это просто фантастика ! Харбор на маке...
А программа тоже под MacOSX работает ?

 Отправлено: 26.05.10 13:56. Заголовок: Andrey пишет: А про..

Andrey пишет:

цитата:

А программа тоже под MacOSX работает ?

Да

 Отправлено: 27.05.10 13:28. Заголовок: alkresin выложил но..

alkresin
выложил новые изменения...

PS вопрос: в связи с чем индексы каждый раз переоткрываются для уже открытой базы (hs_openindex)?
Можно ли это оптимизировать?

 Отправлено: 27.05.10 21:00. Заголовок: alx_on пишет: PS во..

alx_on пишет:

цитата:

PS вопрос: в связи с чем индексы каждый раз переоткрываются для уже открытой базы (hs_openindex)?

Хм... Я этого не замечал, наверное потому что дополнительные ( не compound ) индексы использую только как временные, для одного сеанса работы и не разделяю их с другими экземплярами программы.
Надо как-то исправить, конечно.

 Отправлено: 27.05.10 21:31. Заголовок: Перевел документацию..

Перевел документацию на русский язык
См. readme_rus.txt

 Отправлено: 27.05.10 22:29. Заголовок: Pasha пишет: Переве..

Pasha пишет:

цитата:

Перевел документацию на русский язык

Спасибо Паша !

 Отправлено: 27.05.10 22:39. Заголовок: Реальные проекты с Leto DB Server

Использует ли кто-то в реальных проектах Leto DB Server? Насколько надежно
он ведет себя в работе? Стоит ли на него переходить?

 Отправлено: 27.05.10 22:50. Заголовок: leo Такой же вопрос..

leo
Такой же вопрос можно задать и про ADS.
Лучше всего попробовать самому Leto DB Server.

 Отправлено: 27.05.10 23:54. Заголовок: Уже 5 месяцов

Привет Всем !
Уже 5 месяцов как 3 из моих клиентов перешли на мою новую версию бухучета
пока никаких проблем не замечено

Я использую MiniGUI Ext + Harbour + LetoDB + RPC функциональност от HBNETIO

Есть серверная часть , в которой включен сервер с HBNETIO , и мой RPC функции . Заоодно етот модуль управляет и LetoDB ( Start , Stop , Manager.exe , просмотр Log файла и т.д.)



ну и Клиент

Моя программа зовется "АЛМА" я даже в честь етого сервера новую версию окрестил "АЛМА ЛЕТО"

 Отправлено: 28.05.10 02:19. Заголовок: Interesno

alx_on
Я большой фанат МАКОВ , у меня Хакинтош (ASUS P5QL-PRO , C2D7200 , GF9500 , Leopard 10.5.8) все работает без проблем наверное год и Macbook Pro 17''
У тебя программа консольная на МАКЕ или что то другое ?

 Отправлено: 28.05.10 02:41. Заголовок: sashaBG Harbour + ..

sashaBG

Harbour + ( QT + HbQt )
Win,Linux,MacOSX

 Отправлено: 28.05.10 09:15. Заголовок: alkresin Александр,..

alkresin
Александр, помогите плз разобраться. Может у Вас появится идея. У нас сейчас активно тестируется работа
с LetoDB (сервер на win) и стабильно раз в день (два раза через день) лето падает.
Причем в самых неожиданных местах. Тестеров 5-10 человек. Одновременно открытых таблиц (на всех) 15-200.

Например, одно место:
Скрытый текст

Unrecoverable error 6005: Exception error: %s Exception Code:C0000005 Exception Address:004AAB64 EAX:00000000 EBX:0137BF3C ECX:013F38BC EDX:00000000 ESI:013F39C0 EDI:0000000D EBP:003D66E4 CS:EIP:001B:004AAB64 SS:ESP:0023:01B8F910 DS:0023 ES:0023 FS:003B GS:0000 Flags:00010202 CS:EIP: 0F B7 04 78 89 2C 24 01 D0 89 44 24 04 E8 0A 78 SS:ESP: 003D66E4 018E4604 01B8FC60 004E1B37 018C4B74 01B9147C 01B914DC 004E1B37 01B914DC 00000008 01B8FC60 0000000A 00000000 003C653C 01B99535 0000000F Command: ord;02;18949;opdate;29579;

Я нашел это место - оказалось в драйвере CDX (последний harbour из SVN) в функции hb_dbfGetValue()
Скрытый текст

case HB_FT_DATE: if( pField->uiLen == 3 ) { hb_itemPutDL( pItem, HB_GET_LE_UINT24( pArea->pRecord + pArea->pFieldOffset[ uiIndex ] ) ); } else if( pField->uiLen == 4 ) { hb_itemPutDL( pItem, HB_GET_LE_UINT32( pArea->pRecord + pArea->pFieldOffset[ uiIndex ] ) ); } else { hb_itemPutDS( pItem, ( char * ) pArea->pRecord + pArea->pFieldOffset[ uiIndex ] ); <---- GPF!!! при попытке взять "pArea->pFieldOffset[ uiIndex ]" } break;

Но при таком же тесте в течении 2-3 дней без лето ничего не падает.

 Отправлено: 28.05.10 11:06. Заголовок: alx_on У меня тоже ..

alx_on
У меня тоже такое случалось когда собираю LetoDB с версиями после 2.0.0
поетому я пока его собираю с Harbour 2.0.0 ChangeLog 13372 и не падает

 Отправлено: 28.05.10 11:11. Заголовок: alkresin пишет: доп..

alkresin пишет:

цитата:

дополнительные ( не compound ) индексы использую только как временные, для одного сеанса работы и не разделяю их с другими экземплярами программы

У меня это, к сожалению, норма
Т. е. индексы всегда хранятся отдельно от таблиц (в отдельном каталоге) и они открываются принудительно каждый раз при открытии таблиц

 Отправлено: 28.05.10 11:18. Заголовок: sashaBG пишет: Harb..

sashaBG пишет:

цитата:

Harbour 2.0.0 ChangeLog 13372

Почему именно эта ревизия?

 Отправлено: 28.05.10 13:32. Заголовок: alx_on пишет: У нас..

alx_on пишет:

цитата:

У нас сейчас активно тестируется работа с LetoDB (сервер на win) и стабильно раз в день (два раза через день) лето падает.

В связи с тем, что сказал sashaBG, может, стоит попробовать откомпилировать сервер с другой версией Harbour ...

У меня сейчас работают с letodb сервером 25 - 35 пользователей, 10 - 15 разных приложений, 40 - 60 dbf файлов.
До недавнего времени использовал letodb от августа 2009, он практически не падал, было, пожалуй 2 таких случая за полгода. Когда недели 2-3 назад перешел на последнюю ( с CVS ) версию letodb, он стал падать раз в несколько дней, причем, как я заметил, это обычно происходило во время присоединения нового пользователя, и, как мне кажется, в том случае, если это Windows станция и пользователь запускал программу сразу после включения компьютера, как только появлялся рабочий стол, не дожидаясь полного окончания загрузки Windows. Я так и не понял пока, отчего это могло происходить. Сделал несколько мелких правок в hbip.c b letofunc.c ( Changelog 2010-05-25 11:40 UTC+0300 ), теперь жду результата, за прошедшие 3 дня еще ( тьфу-тьфу ) не падал.

Я нашел еще одно место, которое потенциально может вызывать проблемы. Как вы знаете, в letodb сервере 2 потока. Один слушает сеть, опрашивает открытые сокеты, принимает с них информацию, анализирует команды и выполняет те из них, которые можно обработать на чистом С, без вызова RDD и прочих Harbour level функций, работающих с vm, стеком. 2-й поток обрабатывает остальные команды. Так вот, сейчас первый поток вызывает и функцию leto_CloseUS() - закрытие клиента, которая, если есть еще у него незакрытые areas, закрывает их, т.е. выполняет действия, предназначеннные для 2-го потока, что теоретически может вызвать неприятные коллизии. Это может происходить, если вы "убиваете" пользователя из manage или если связь с ним по какой-то причине внезапно обрывается ( при нормальном завершении задачи Harbour сам закрывает открытые areas и такого не происходит ).

 Отправлено: 28.05.10 13:40. Заголовок: ( В продолжение к пр..

( В продолжение к предыдущему )
Ну и, раз у вас индексы открываются так, как вы описали, то, учитывая эту ошибку в hs_openindex, даже не представляю, как оно вообще у вас работает...

 Отправлено: 28.05.10 13:41. Заголовок: Stable

alx_on
Я не такой спец в C и поетому не стал копть в GPF а просто вернулся на stable версию Harbour с www.harbour-project.org
Да конечно и мне тоже хочется скомпилировать все одной и той же весрии Harbour . Может господин Кресин действительно поможет !

 Отправлено: 28.05.10 13:54. Заголовок: alkresin пишет: даж..

alkresin пишет:

цитата:

даже не представляю, как оно вообще у вас работает...

Я вообще не представлял что оно будет на работать на маке, но ведь работает
хотя в коде есть конкретные вставки только под win и linux (я не вникал что там, приоритет пока на вин-платформу)

по поводу индексов: просто переоткрывает и память переинициализирует (вопрос насколько корректно?)

цитата:

стоит попробовать откомпилировать сервер с другой версией Harbour

не могу - многое завязано на новой версии (например, HbQT)

Может это быть связано с массовой переделкой типов (ULONG на HB_MAXINT и т.д.)?

цитата:

если связь с ним по какой-то причине внезапно обрывается

вот, кстати, по поводу связи: если хоть на миг связь прерывается (например, комп почти успел уйти в сон, но почти успели двинуть мышой ), то все соединения с лето на клиенте рвутся (соответственно ни работать дальше нельзя, ни закрыть нормально, куча ошибок выходит на каждую открытую таблицу)

 Отправлено: 28.05.10 14:40. Заголовок: alx_on пишет: не мо..

alx_on пишет:

цитата:

не могу - многое завязано на новой версии (например, HbQT)

Так перекомпилите только сервер, клиенты пусть остаются как есть.

цитата:

Может это быть связано с массовой переделкой типов (ULONG на HB_MAXINT и т.д.)?

Если вы перекомпилите сервер с другой версией Harbour и он перестанет падать, тогда будет иметь смысл подумать об этом.

цитата:

вот, кстати, по поводу связи: если хоть на миг связь прерывается (например, комп почти успел уйти в сон, но почти успели двинуть мышой ), то все соединения с лето на клиенте рвутся

Хм.. А что, связь прерывается при уходе в сон ? Я сейчас специально 2 раза вышел при открытой программе в ждущий режим ( через Пуск...Выключение ) - после пробуждения все работало как прежде. А вообще при прерывании связи клиент принудительно отключается, а что еще с ним делать ?

 Отправлено: 28.05.10 15:00. Заголовок: alkresin пишет: Есл..

alkresin пишет:

цитата:

Если вы перекомпилите сервер с другой версией Harbour

Надо будет попробовать. На какой версии остановиться?

цитата:

Я сейчас специально 2 раза вышел при открытой программе в ждущий режим

странно... у меня все отвалилось

цитата:

при прерывании связи клиент принудительно отключается, а что еще с ним делать ?

Подождать какое то время, например, и переподключать. Но это так, мечты...

PS может быть такая ситуация: на сетевом уровне пакет (строка с командой) пришла не полностью?

 Отправлено: 28.05.10 17:17. Заголовок: alx_on пишет: Надо ..

alx_on пишет:

цитата:

Надо будет попробовать. На какой версии остановиться?

Предлагаю какую-нибудь до появления mt, у меня, например, 1.01 стоит.

цитата:

PS может быть такая ситуация: на сетевом уровне пакет (строка с командой) пришла не полностью?

Такая ситуация предусмотрена. Сервер опрашивает сокет, пока не обнаружит конца пакета. Сокет отключается и клиент удаляется только в случае если в результате опроса сокета была возвращена ошибка.

 Отправлено: 28.05.10 18:11. Заголовок: alkresin пишет: Со..

alkresin пишет:

цитата:

Сокет отключается и клиент удаляется

Имелось в виду падение сервера, т.е. разбор неполной строки с командой

 Отправлено: 28.05.10 19:00. Заголовок: alkresin пишет: Пре..

alkresin пишет:

цитата:

Предлагаю какую-нибудь до появления mt, у меня, например, 1.01 стоит

Подскажете точные ключи компиляции для винды (чтобы быть уверенным в результате)
можно и для linux

И плюс для самого лета

PS там на компилятор есть ограничение? Я использую mingw почти последний

 Отправлено: 28.05.10 19:29. Заголовок: alx_on пишет: Подск..

alx_on пишет:

цитата:

Подскажете точные ключи компиляции для винды (чтобы быть уверенным в результате) можно и для linux

Я не ставлю никаких своих дополнительных ключей, что есть в стандартных файлах конфигурации, то и использую.
То же для лета - один к одному как на CVS.

цитата:

PS там на компилятор есть ограничение? Я использую mingw почти последний

С mingw не пробовал, ничего не могу сказать. Клиентов я компилирую с Borland 5.5, а сервер у меня на Линукс.

 Отправлено: 28.05.10 19:30. Заголовок: sashaBG пишет: соби..

sashaBG пишет:

цитата:

собираю с Harbour 2.0.0 ChangeLog 13372

Попробовал с 2.0
Не компиляет!

funcleto.h:138: error: redefinition of typedef ‘HB_ERRCODE’
harbour2.0/include/hbapi.h:473: error: previous declaration of ‘HB_ERRCODE’ was here

Придется разбираться :)

 Отправлено: 28.05.10 19:32. Заголовок: alx_on пишет: Имело..

alx_on пишет:

цитата:

Имелось в виду падение сервера, т.е. разбор неполной строки с командой

Разбора неполной строки быть не может - протокол предусматривает определение конца пакета и пока этот конец не будет определен, разбор строки не начнется.

 Отправлено: 28.05.10 19:33. Заголовок: alkresin пишет: Я н..

alkresin пишет:

цитата:

Я не ставлю никаких своих дополнительных ключей, что есть в стандартных файлах конфигурации, то и использую

В смысле просто make?

 Отправлено: 28.05.10 19:38. Заголовок: alx_on пишет: В смы..

alx_on пишет:

цитата:

В смысле просто make?

В той версии, которой я пользуюсь, еще есть make_b32.bat и make_b32.mak, там еще не используется gnu make :)

 Отправлено: 28.05.10 19:41. Заголовок: Это для Windows. А д..

Это для Windows. А для Линукс - да, просто make, и перед ним устанавливаю несколько переменных окружения:
export HB_ARCHITECTURE=linux
export HB_COMPILER=gcc
export HB_GT_LIB=gtcrs

 Отправлено: 28.05.10 20:17. Заголовок: Посмотрел внимательн..

Посмотрел внимательнее hs_openindex, там вроде бы все в порядке, ничего не переоткрывается, ничего не переинициализируется.

 Отправлено: 28.05.10 20:51. Заголовок: Павел, что-то после ..

Павел, что-то после ваших сегодняшних изменений "for compatibility with older xHarbour versions" у меня перестало компилироваться:

source\server\server.prg(110) Error F0029 Can't open #include file: 'hbextcdp.ch'
...
Error: Unresolved external '_hb_GetSetStructPtr' referenced from C:\MYAPPS\LETODB\OBJ\B32\LETOFUNC.OBJ

 Отправлено: 28.05.10 21:44. Заголовок: Я проверял сборку дл..

Я проверял сборку для Harbour с SVN, поэтому получилась такая неувязка.

с _hb_GetSetStructPtr понятно, я сейчас поправлю. У меня Harbour 1.х нет, но суть ясна.

А с source\server\server.prg(110) какие-то чудеса, а поскольку чудес не существует, видимо баг в препроцессоре
Я собирал letodb с xharbour 1.01, и на строке 105, в ветке для Harbour, которую xHarbour не должен компилировать:

#if ( (HB_VER_SVNID - 0) > 11796 )

получил ошибку на #if

я заменил конструкцию:

#if defined(HB_VER_SVNID)
#if ( (HB_VER_SVNID - 0) > 11796 )
#define __HB_EXT_CDP__
#endif
#endif

на идентичную:

#if defined(HB_VER_SVNID) && ( (HB_VER_SVNID - 0) > 11796 )
#define __HB_EXT_CDP__
#endif

ошибка в xharbour исчезла, но появилась непонятная ошибка в Harbour

Я конечно верну все назад, но фокусы с препроцессором непонятны

 Отправлено: 29.05.10 10:20. Заголовок: alkresin пишет: Пос..

alkresin пишет:

цитата:

Посмотрел внимательнее hs_openindex, там вроде бы все в порядке

Я вставил отладочные сообщения - hs_openindex каждый раз отрабатывает, т.е.
OrdListAdd( cBagName )
OrdSetFocus( OrdCount() )
хотя таблица с таким индексным файлом уже открыта и используется

 Отправлено: 29.05.10 13:41. Заголовок: Pasha пишет: А с so..

Pasha пишет:

цитата:

А с source\server\server.prg(110) какие-то чудеса, а поскольку чудес не существует, видимо баг в препроцессоре

Да, по-видимому, в тех версиях такие конструкции вызывают ошибки. Я уже сталкивался с этим.

 Отправлено: 29.05.10 13:43. Заголовок: alx_on пишет: Я вст..

alx_on пишет:

цитата:

Я вставил отладочные сообщения - hs_openindex каждый раз отрабатывает, т.е. OrdListAdd( cBagName ) OrdSetFocus( OrdCount() ) хотя таблица с таким индексным файлом уже открыта и используется

Да, отрабатывает. Но если вы посмотрите на реализацию OrdListAdd() d dbfcdx и dbfntx ( я вчера посмотрел :) ), то увидите, что там проверяется, открыт ли уже этот индекс, и, если открыт, не делается ничего.

 Отправлено: 31.05.10 19:05. Заголовок: Нашел интересную зав..

Нашел интересную зависимость под win

Если стоит "microsoft visual C++ 2008 Redistributable - x86 9.0.21022"
то лето падает (как мной описано постами выше)
если удалить (стандартно), то не падает

(конечно, может и неверно лето работает, например, ошибки по памяти остаются, но молча пропускаются )

 Отправлено: 01.06.10 08:20. Заголовок: alx_on пишет: Если ..

alx_on пишет:

цитата:

Если стоит "microsoft visual C++ 2008 Redistributable - x86 9.0.21022" то лето падает (как мной описано постами выше) если удалить (стандартно), то не падает

Интересно... А каким С компилятором у вас letodb скомпилирован ? MSVS ? Если да, то той же версии, что и Redistributable ?

 Отправлено: 01.06.10 09:39. Заголовок: alkresin пишет: С к..

alkresin пишет:

цитата:

С компилятором у вас letodb скомпилирован ?

MinGW

Но суть не в этом. Я нашел проблему! По крайней мере одну из... :)
При передаче значений полей возникает путаница, если кол-во полей в таблице > 255
Там такой бардак начинается, что диву даешься как это все работало
Попытаюсь сегодня выложить предварительные исправления

PS Александр, вопрос: в старом harbour и xHarbour есть функции (правильно! работающие под разные ОС)
hb_osPathSeparator()
hb_osDriveSeparator()
hb_osNewLine()

 Отправлено: 01.06.10 10:30. Заголовок: alx_on пишет: PS Ал..

alx_on пишет:

цитата:

PS Александр, вопрос: в старом harbour и xHarbour есть функции (правильно! работающие под разные ОС) hb_osPathSeparator() hb_osDriveSeparator() hb_osNewLine()

Функции есть, ну а правильно они работают или нет - не проверял. Наверное, правильно :).

 Отправлено: 01.06.10 10:58. Заголовок: alkresin пишет: Фун..

alkresin пишет:

цитата:

Функции есть

Предлагаю их использовать вместо прямых указаний "/", "\" и перевода строк
все пути в коде сервера переводить на нативный вариант текущей оси сервера
(путаница возникает при использовании на клиентских местах разных ОС)

 Отправлено: 01.06.10 11:23. Заголовок: Предлагаю их использ..

цитата:

Предлагаю их использовать вместо прямых указаний "/", "\" и перевода строк

Не возражаю. А перевод строк где нам нужен ?

цитата:

все пути в коде сервера переводить на нативный вариант текущей оси сервера

Так они переводятся, только с использованием напрямую "/", "\"

 Отправлено: 01.06.10 12:28. Заголовок: alkresin пишет: А п..

alkresin пишет:

цитата:

А перевод строк где нам нужен

В логах, например

цитата:

Так они переводятся,

Не везде

Вопрос: для чего в letoOrderCreate() после успешного создания индекса нужно делать SELF_GOTOP()?
Во первых это лишний вызов (у меня в CDX-файле штук 10 ордеров и 10 gotop соответственно мне не нужны,
после создания последнего может и надо, и то не в моем случае)
Столкнулся со странной ситуацией - на ОДИН файл не может создать индекс (причем, подобные файлы с такой же структурой - ок)
именно "return SELF_GOTOP( ( AREAP ) pArea )" возвращает ошибку!

upd!
Ошибся! Сделал
SELF_GOTOP( ( AREAP ) pArea );
return SUCCESS;
- тоже самое
Ничего не понимаю

 Отправлено: 01.06.10 13:14. Заголовок: Вопрос: для чего в l..

цитата:

Вопрос: для чего в letoOrderCreate() после успешного создания индекса нужно делать SELF_GOTOP()?

Потому что так ведет себя эта функция во всех RDD.

цитата:

именно "return SELF_GOTOP( ( AREAP ) pArea )" возвращает ошибку!

Ошибку - в смысле run-time error с соответствующими gencode, subcode ? Если так, то что дает return SUCCESS, если эта runtime error уже произошла во время исполнения SELF_GOTOP ...

 Отправлено: 01.06.10 13:20. Заголовок: alkresin пишет: во ..

alkresin пишет:

цитата:

во время исполнения SELF_GOTOP

В чем может быть проблема?

в функциях
letoGoTop() в leto1.c
leto_Goto() в letofunc.c
ошибки не возникают...

 Отправлено: 01.06.10 13:37. Заголовок: В чем может быть про..

цитата:

В чем может быть проблема? в функциях letoGoTop() в leto1.c leto_Goto() в letofunc.c ошибки не возникают...

Как я понял, эта ошибка происходит у вас при создании одного определенного индекса - т.е. сразу после его создания программа вываливается, так ? Значит, letoGoTop() для этого индекса не вызываются, или я не так понял ?
А вот почему именно этот индекс вызывает ошибку надо смотреть. Создался он на сервере или нет, нормальный ли он ( открывается ли с dbfcdx ), какую именно ошибку вернул сервер. Мне, чтобы предметно об этом говорить, нужен самодостаточный пример, чтоб я мог его воспроизвести.

 Отправлено: 01.06.10 17:11. Заголовок: alkresin пишет: сра..

alkresin пишет:

цитата:

сразу после его создания программа вываливается, так ?

да

цитата:

Значит, letoGoTop() для этого индекса не вызываются

только что еще раз проверил - вызывается

цитата:

Создался он на сервере или нет, нормальный ли он ( открывается ли с dbfcdx )

да и да

самодостаточный пример попытаюсь сделать
PS пока баловался - сделал нечаянно тот же самый индекс с параметром DESCENDING - прошло без ошибок

 Отправлено: 02.06.10 08:31. Заголовок: В присланном вами te..

В присланном вами test.dbf есть "нехорошая запись" ( recno() = 61 ) с несимвольной информацией - похоже, битая. После индексирования она становится 1-й и при Gotop() на нее получается ошибка - этим объясняется, почему с descending все работает ( первой становится другая запись ). После удаления этой записи и упаковки все работает нормально. Это, впрочем, не отменяет того факта, что ошибка возвращаться не должна - надо смотреть, в чем дело.

 Отправлено: 02.06.10 09:48. Заголовок: Исправил я это дело,..

Исправил я это дело, проблема была в битом поле типа DATE.
Кстати, Александр, начал я смотреть ваши изменения - что-то вы в common_c.c форматирование сбили, там теперь разделитель строк не r\n, а \r\r\n

 Отправлено: 02.06.10 09:58. Заголовок: alkresin пишет: раз..

alkresin пишет:

цитата:

разделитель строк не r\n, а \r\r\n

Знаю :)
я уже пытался выложить изменения, но меня опередили и теперь опять синхронизирую

уффф, выложил
проверьте плз

 Отправлено: 02.06.10 10:38. Заголовок: уффф, выложил провер..

цитата:

уффф, выложил проверьте плз

С common_c.c все в порядке.

 Отправлено: 02.06.10 11:16. Заголовок: alkresin пишет: Исп..

alkresin пишет:

цитата:

Исправил я это дело, проблема была в битом поле типа DATE.

Может быть более жесткую проверку сделать (только цифры)? Может возникнуть аналогичная ситуация, но символ будет, например, больше пробела

 Отправлено: 02.06.10 12:11. Заголовок: Может быть более жес..

цитата:

Может быть более жесткую проверку сделать (только цифры)? Может возникнуть аналогичная ситуация, но символ будет, например, больше пробела

Нет особой необходимости. Вообще говоря, там достаточно было добавить проверку на \0, беда была именно в этом. Сервер передавал 8 нулей из битой записи, а клиент, а ведь \0 в первом байте - признак пустого поля. Клиент, обнаружив его, начинал читать следующее поля со следующего байта - и запутался.

 Отправлено: 02.06.10 13:06. Заголовок: после изменений в фа..

после изменений в файле funcleto.h

#define hb_cdp_page hb_cdppage()
#if defined(HB_ERRCODE)
typedef HB_ERRCODE ERRCODE;
#endif

не компилится в xHarbour (121_6714)
если вернуть назад, всё нормально проходит
перед этим была одна ошибка в препроцесоре в файле server.prg, она и осталась, причина ошибки пока непонятна.

 Отправлено: 02.06.10 13:18. Заголовок: Александр, после пос..

Александр, после последних изменений появилась проблема ( с 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

Сервер падает. Где-то у вас ошибка закралась...

 Отправлено: 02.06.10 13:25. Заголовок: И еще вопрос по изме..

И еще вопрос по изменениям в протоколе:
он изменился только для файлов с количеством полей > 256, или для всех ? Т.е., могу ли я компилировать приложения с новой версией, не трогая сервер ( у меня нет файлов с таким большим количеством полей ) ?

 Отправлено: 02.06.10 13:41. Заголовок: alkresin пишет: мог..

alkresin пишет:

цитата:

могу ли я компилировать приложения с новой версией

Да.
Фактически это не изменение, а исправление

Ошибку с DbSkip() поправил (тупо else пропустил как то )

 Отправлено: 02.06.10 13:51. Заголовок: А на CVS исправления..

А на CVS исправления еще не запостили ?

 Отправлено: 02.06.10 13:55. Заголовок: alkresin пишет: А н..

alkresin пишет:

цитата:

А на CVS исправления еще не запостили ?

Выложил

У меня все равно где то падает собака!
Поймать не могу
(переход на harbour 1.01 для меня - -как совсем крайний случай :) )

 Отправлено: 02.06.10 14:01. Заголовок: Так а падает на harb..

Так а падает на harbour 1.01 или не проверяли ? Я согласен, что откат на старую версию - не выход, но такая проверка может подтолкнуть в правильном направлении.
P.S. Падает и без установленных MSVS Redistributable ?

 Отправлено: 02.06.10 14:37. Заголовок: alkresin пишет: Так..

alkresin пишет:

цитата:

Так а падает на harbour 1.01 или не проверяли ?

Пока руки не дошли

цитата:

P.S. Падает и без установленных MSVS Redistributable ?

Скорее всего молча пропускает ошибки
Потому как с MSVS Redistributable отладчик (gdb) показывает ошибку примерно такого плана:
неверный вызов (или неверные параметры вызова, точно не помню) С-функций (или библиотечных)
Т.е. более жесткая проверка параметров вызова стандартных библиотечных функций

 Отправлено: 02.06.10 16:53. Заголовок: Проявляется при инте..

Проявляется при интенсивной нагрузке с одной машины (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, что является ошибкой

 Отправлено: 02.06.10 23:26. Заголовок: Выложил новые измене..

Выложил новые изменения
Обработка ошибки сети
Решение временное, надо по другому как то реализовать
Но как затычка пойдет

Проверьте у себя внимательно плз
Тестировал интенсивно у себя в течении часа. На последнем harbour с SVN!
То что раньше падало, максимум, через 20 минут - не упало!
Может совпало с погодой? :)
PS да, на предмет целостности данных не сильно смотрел, но вроде не должно это повлиять :)

 Отправлено: 03.06.10 09:12. Заголовок: Очень интересно! Здо..

Очень интересно! Здорово, что вы на это вышли, Александр.
Пожалуй, hb_ipAccept() стоит немного изменить. Получается, что если accept() завершился с ошибкой ( вернул -1 ), но последующий WSAGetLastError() ( или errno для Линукс ) вернул 0, то все вроде-бы в порядке и для этого -1 вызываются другие функции. А ситуация такая может быть, если между вызовами accept() и WSAGetLastError() вклинился другой thread со своими socket вызовами и библиотека сокетов не thread safe.

 Отправлено: 03.06.10 09:44. Заголовок: Я поменял немного hb..

Я поменял немного hb_ipAccept() в свете того, что писал ранее, надеюсь - будет работать.

 Отправлено: 03.06.10 20:28. Заголовок: Поправил баг, связан..

Поправил баг, связанный с установкой кодовой страницы на сервере. По-видимому, он возник после добавления авторизации пользователей: 6-й и более параметры команды intro просто игнорировались

 Отправлено: 03.06.10 20:40. Заголовок: Александр, наверное ..

Александр, наверное еще в srvleto.h - USERSTRU надо добавить:
USHORT uiVarsOwnCurr;

 Отправлено: 04.06.10 07:55. Заголовок: Александр, наверное ..

цитата:

Александр, наверное еще в srvleto.h - USERSTRU надо добавить: USHORT uiVarsOwnCurr;

Точно, забыл этот файл переписать.

 Отправлено: 05.06.10 10:54. Заголовок: Вчера опять падало, ..

Вчера опять падало, 3 раза (сервер вин2008)

Все три раза так:

(gdb)
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.

В двух случаях в логах ничего нет, только выходит предупреждение винды
На третий в логе странная запись:

06/04/10 15:49:17: Error BASE/1081 Argument error: +
Arguments: ( [ 1] = Type: C Val: +6707;0;23;ACCNAME;C;100;0;ACC;C;9;0;CTYPE;N;1;0;GROUP;N;2;0;DOCDEB;C;250;0;DOCKRED;C;250;0;TSALDO;N;1;0;KEYF1;C;6;0;KEYF2;C;6;0;KEYF3;C;6;0;STYPE;N;1;0;INDEPEND;L;1;0;PRICE;N;1;0;ATYPE;L;1;0;KGU;L;1;0;PREDOK;C;12;0;RECCODE;C;12;0;TYPE;L;1;0;KGUDEBET;C;6;0;KGUKREDIT;C;6;0;GRKBK;N;2;0;ACCKF;C;6;0;LDOG;L;1;0;6;accnt;ACCNT;FIELD->ACC;;C;9;accnt;GRP;IF(TYPE,"1","0")+STRZERO( FIELD->GROUP, 2 );;C;3;accnt;GRPACC;IF(TYPE,"1","0")+STRZERO( FIELD->GROUP, 2 ) + FIELD->ACC;;C;12;accnt;SELECT;IF(TYPE,"1","0");;C;1;accnt;PREDOK;FIELD->PREDOK;;C;12;accnt;ACCKF;FIELD->ACCKF;;C;6;, [ 2] = Type: N Val: 0)


Похоже только на одно место - server.prg (функция hs_opentable)
cReply += leto_rec( nId, nUserStru )
Бред какой то...

 Отправлено: 05.06.10 12:07. Заголовок: Александр, а как сде..

Александр, а как сделать, чтобы для выполнения функции leto_sum() создавался отдельный поток, и чтобы это работало в обеих харборах ?
Выполнение в отдельном потоке может понадобиться и для других потенциально тяжелых операций.

 Отправлено: 05.06.10 13:49. Заголовок: На досуге посмотрел ..

На досуге посмотрел почему по времени локально лето и CDX отличаются в 2 раза (не в пользу лето)
Половину времени занимает выполнение leto_SendAnswer()
Александр, как думаете с чем это связано? Почему так медленно? Все локально, т.е. аппаратная часть не влияет, дрова аналогично
Может перейти на асинхронный способ передачи?
(плюс непонятные падения сервера - стоит использовать thread safe? Полностью перейти на последний harbour с его MT? Я понимаю,
что Вы используете старую версию и вряд ли захотите влезать в проблемы перехода на новую версию, но может стоит попробовать?
У данного перехода есть плюс - можно, например, запускать несколько потоков для обслуживания либо разных подключений
либо таблиц. Т.е. равномерно распределять открываемые таблицы между потоками при большой загрузке)

 Отправлено: 05.06.10 14:14. Заголовок: Добавил для leto_sum..

Добавил для leto_sum возможность суммирования нескольких полей:

leto_sum("Sum1,Sum2", cFilter, cScopeTop, cScopeBottom) вернет массив значений {nSum1, nSum2}

Если в качестве имеени поля задать символ "#", будет расчитано количество записей в выборке
Для одного поля функция, как и раньше, возвращает числове значение - сумму.

 Отправлено: 07.06.10 09:13. Заголовок: Александр, а как сде..

цитата:

Александр, а как сделать, чтобы для выполнения функции leto_sum() создавался отдельный поток, и чтобы это работало в обеих харборах ?

цитата:

Полностью перейти на последний harbour с его MT?

Реализация дополнительных потоков Harbour-уровня мне не кажется реальной. Для этого потребуется переписывать ядро letodb целиком с тем,
чтобы сделать многопоточность на базе Harbour - реализации, а не на тех методах, что используются сейчас. Возможно ли при этом обеспечить
совместимость с xHarbour на С уровне - большой вопрос. Я не знакомился с особенностями реализации mt ни в Harbour, ни в xHarbour, но из общих
соображений мне это представляется более чем проблематичным.
Есть еще одна ( да не одна, наверное :) ) проблема. Я внимательно читал Харборовский мэйллист периода внедрения mt - Przemek особенно подчеркивал,
нельзя в параллельных потоках работать с одной таблицей. Если с тех пор ничего не изменилось, то реализация, например, leto_sum() в отдельном потоке
возможна лишь при открытии файла в exclusive режиме, что, в общем случае, неприемлемо.
Я изначально предполагал для "потенциально тяжелых операций" использовать отдельные процессы, именно поэтому в letodb включен механизм "shared memory",
но тут тоже не все просто, я пока не собрался приступить к этому поближе.

 Отправлено: 07.06.10 09:19. Заголовок: Вчера опять падало, ..

цитата:

Вчера опять падало, 3 раза (сервер вин2008)

Вот зараза!

цитата:

warning: Invalid parameter passed to C runtime function.

Может опять поставить ту проверку в hb_ip_rfd_set() ? Я ее убрал, решив что она уже не нужна ...

цитата:

Похоже только на одно место - server.prg (функция hs_opentable) cReply += leto_rec( nId, nUserStru ) Бред какой то...

Думаю, это случайность. Скорее всего, ошибка произошла во время выполнения параллельного потока.

 Отправлено: 07.06.10 09:36. Заголовок: alkresin пишет: Ест..

alkresin пишет:

цитата:

Есть еще одна ( да не одна, наверное :) ) проблема. Я внимательно читал Харборовский мэйллист периода внедрения mt - Przemek особенно подчеркивал, нельзя в параллельных потоках работать с одной таблицей. Если с тех пор ничего не изменилось, то реализация, например, leto_sum() в отдельном потоке возможна лишь при открытии файла в exclusive режиме, что, в общем случае, неприемлемо.

Я тоже учитывал этот момент, когда прокручивал алгоритм "в голове". Такой конфликт можно разрешить блокировкой отдельных таблиц на уровне leto. То есть, пока leto_sum не отработает, другой клиент "висит" на skip по этой же таблице, и наоборот. Это намного лучше, чем сейчас, когда все клиенты ждут, пока не завершится leto_sum.

 Отправлено: 07.06.10 09:37. Заголовок: На досуге посмотрел ..

цитата:

На досуге посмотрел почему по времени локально лето и CDX отличаются в 2 раза (не в пользу лето) Половину времени занимает выполнение leto_SendAnswer()

На локальной машине letodb в принципе должно быть медленнее dbfcdx - для выполнения каждой операции сервером выполняются те же
методы dbfcdx плюс затраты на прием команды и передачу ответа, а время выполнения tcp/ip приема/передачи ( на сервере + на клиенте )
вполне может быть сравнимо со временем выполнения некоторых RDD методов.

цитата:

Может перейти на асинхронный способ передачи?

Я не вижу, как это ускорит реакцию. Сервер и так, когда он не занят выполнением команды, ждет прихода новой и сразу берется за ее исполнение.
А на посылку ответа ( leto_SendAnswer() ) это вообще никак не повлияет.

Может, стоит поиграть настройками TCP/IP - как в hbip.c, так и на компьютере ...

 Отправлено: 07.06.10 10:02. Заголовок: К слову. По сети let..

К слову. По сети leto может превосходить dbfcdx по производительности в разы.
К примеру, я взял отчет, в котором выполнятся выборка из 3-х таблиц за большой промежуток времени. С dbfcdx он рассчитывался 75 сек, с letodb - 13 сек. Причем никакой отимизации для leto не делал, обьем данных, которые выбираются из таблиц - один к одному. А если еще применить клиент-серверные средства, ограничив обьем данных, передаваемых по сети, разница еще увеличится.
Это конечно не общий случай, но все-таки маленький факт.

 Отправлено: 07.06.10 10:34. Заголовок: alkresin пишет: нел..

alkresin пишет:

цитата:

нельзя в параллельных потоках работать с одной таблицей.

Не знаю как в xHarbour. В Harbour это сделано прозрачно на основе эмуляции XBase++. Передача таблицы между потоками:
HB_DBDETACH() и HB_DBREQUEST()
Можно без этого - просто распределять открываемые таблицы между потоками, быстрее отклик, лучше отзывчивость, например, в TbBrowse

цитата:

А на посылку ответа ( leto_SendAnswer() ) это вообще никак не повлияет

Это повлияет на скорость исполения команд, т.к. поток не будет ждать завершения отсылки ответа, он сразу примется за обработку следующей команды.

цитата:

На локальной машине letodb в принципе должно быть медленнее dbfcdx

Локальную машину я привел в пример для исключения влияния железа. Я знаю, что CDX медленнее по сети работает, но у меня есть результаты сравнения с ADS на тех же операциях (она по сети быстрее в 1.5-2 раза)

Вообще я не критикую лето, это для меня единственная альтернатива платной ADS
Я хочу ее развить (или, по крайней мере приблизить) до уровня ADS

 Отправлено: 07.06.10 11:03. Заголовок: Такой конфликт можн..

цитата:

Такой конфликт можно разрешить блокировкой отдельных таблиц на уровне leto. То есть, пока leto_sum не отработает, другой клиент "висит" на skip по этой же таблице, и наоборот.

цитата:

Не знаю как в xHarbour. В Harbour это сделано прозрачно на основе эмуляции XBase++. Передача таблицы между потоками: HB_DBDETACH() и HB_DBREQUEST() Можно без этого - просто распределять открываемые таблицы между потоками

Да, этот вопрос, наверное, можно решить. Но остается главный - переписать реализацию mt, да так, чтобы обеспечить совместимость Harbour с xHarbour на C уровне. На prg уровне это, наверное, сделать легче, но тогда придется и ядро letodb переводить на prg уровень, что приведет к общему снижению производительности. Я бы предпочел лучше попробовать с процессами.