mORMot Open Source

Yes, with your last patch it works as expected.

Yes, it was rkUnknown.

Yes, I do always a clean & build under lazarus. But mormot.core.linux.inc? Do you mean mormot.core.os.posix.inc?

Ok, than no progress at all:

mutex_unlock_common (m=0x90134b708, cv=false, mtx_defer=0x0)
    at /usr/src/lib/libthr/thread/thr_mutex.c:976
976        if (__predict_false(PMUTEX_OWNER_ID(m) != id))
(gdb) backtrace 10
#0  mutex_unlock_common (m=0x90134b708, cv=false, mtx_defer=0x0)
    at /usr/src/lib/libthr/thread/thr_mutex.c:976
#1  0x0000000000434b49 in CTHREADS_$$_CLEAVECRITICALSECTION$formal ()
#2  0x00000000004254ca in SYSTEM_$$_LEAVECRITICALSECTION$POINTER ()
#3  0x00000000004dcae3 in DOREGISTER (this=0x801de8370, INFO=0xeb7b68)
    at ../../mORMot2/src/core/mormot.core.rtti.pas:8630
#4  0x00000000004dd357 in SETGLOBALCLASS (this=0x801de8370,
    RTTICLASS=0x1004fa0) at ../../mORMot2/src/core/mormot.core.rtti.pas:8751
#5  0x000000000094f8bd in INITIALIZEUNIT ()
    at ../../mORMot2/src/core/mormot.core.json.pas:11687
#6  0x000000000094f979 in MORMOT.CORE.JSON_$$_init$ ()
    at ../../mORMot2/src/core/mormot.core.json.pas:11699
#7  0x0000000000421652 in fpc_initializeunits ()
#8  0x0000000000403b9f in main () at SOneSrv2.dpr:551

If a do a breakpoint in thr_mutex.c for mutex_lock_common and mutex_unlock_common, than I can see, that this function will be called.
Are you sure, a confusion of libc and libthr functions exists?

@DonAlfredo
This patch is already included in R13.2 and it couldn't be an issue on linker side.

Thanks a lot for your hint!

with TLightLock app hangs when leaving InizializeUnit in mormot.core.log. After stepping over end; Debugger shows end; of FinalizeUnit.

Assembler show this:
0000000000421472 eb55                     jmp    0x4214c9 <fpc_initializeunits+121>

0000000000421474 48c745f800000000         movq   $0x0,-0x8(%rbp)
000000000042147C 488b45f8                 mov    -0x8(%rbp),%rax
0000000000421480 488d4001                 lea    0x1(%rax),%rax
0000000000421484 488945f8                 mov    %rax,-0x8(%rbp)
0000000000421488 488b45f8                 mov    -0x8(%rbp),%rax
000000000042148C 48c1e004                 shl    $0x4,%rax
0000000000421490 488d15a99ba100           lea    0xa19ba9(%rip),%rdx        # 0xe3b040 <INITFINAL>
0000000000421497 48833c0200               cmpq   $0x0,(%rdx,%rax,1)
000000000042149C 7502                     jne    0x4214a0 <fpc_initializeunits+80>
000000000042149E eb12                     jmp    0x4214b2 <fpc_initializeunits+98>
00000000004214A0 488b45f8                 mov    -0x8(%rbp),%rax
00000000004214A4 48c1e004                 shl    $0x4,%rax
00000000004214A8 488d15919ba100           lea    0xa19b91(%rip),%rdx        # 0xe3b040 <INITFINAL>
00000000004214AF ff1402                   call   *(%rdx,%rax,1)
00000000004214B2 488d05879ba100           lea    0xa19b87(%rip),%rax        # 0xe3b040 <INITFINAL>
00000000004214B9 488b55f8                 mov    -0x8(%rbp),%rdx
00000000004214BD 48895008                 mov    %rdx,0x8(%rax)
00000000004214C1 483b5df8                 cmp    -0x8(%rbp),%rbx
00000000004214C5 7602                     jbe    0x4214c9 <fpc_initializeunits+121>
00000000004214C7 ebb3                     jmp    0x42147c <fpc_initializeunits+44>
00000000004214C9 488d0550aea100           lea    0xa1ae50(%rip),%rax        # 0xe3c320 <TC_$SYSTEM_$$_INITPROC>
00000000004214D0 48833800                 cmpq   $0x0,(%rax)
00000000004214D4 7502                     jne    0x4214d8 <fpc_initializeunits+136>
00000000004214D6 eb09                     jmp    0x4214e1 <fpc_initializeunits+145>
00000000004214D8 488d0541aea100           lea    0xa1ae41(%rip),%rax        # 0xe3c320 <TC_$SYSTEM_$$_INITPROC>
00000000004214DF ff10                     call   *(%rax)
00000000004214E1 488b5df0                 mov    -0x10(%rbp),%rbx
00000000004214E5 4889ec                   mov    %rbp,%rsp
00000000004214E8 5d                       pop    %rbp

Now with TLightLock my real app hangs at starting and I have to find out where.

TLightLock works!
TOSLightLock not.

the segfault comes from thr_mutex.c when the CS will be unlocked a second time:

/*
* Check if the running thread is not the owner of the mutex.
*/
if (__predict_false(PMUTEX_OWNER_ID(m) != id)) <-- here
  return (EPERM);

This comes from the second step of a for loop in mormot.core.rtti which calls

function TRttiCustomList.DoRegister(Info: PRttiInfo): TRttiCustom;

and here the finally RegisterSafe.UnLock;
calls in thr_mutex.c

mutex_unlock_common(struct pthread_mutex *m, bool cv, int *mtx_defer)

stack trace:
#0  mutex_unlock_common (m=0x90138e708, cv=false, mtx_defer=0x0) at /usr/src/lib/libthr/thread/thr_mutex.c:976
#1  0x0000000000431c19 in CTHREADS_$$_CLEAVECRITICALSECTION$formal ()
#2  0x00000000004ee651 in UNLOCK (this=...) at ../../mORMot2/src/core/mormot.core.os.pas:9003
#3  0x00000000004d9e59 in DOREGISTER (this=0x801637188, INFO=0xea9f78) at ../../mORMot2/src/core/mormot.core.rtti.pas:8629
#4  0x00000000004da677 in SETGLOBALCLASS (this=0x801637188, RTTICLASS=0xff6df0) at ../../mORMot2/src/core/mormot.core.rtti.pas:8750
#5  0x000000000094bffd in INITIALIZEUNIT () at ../../mORMot2/src/core/mormot.core.json.pas:11679
#6  0x000000000094c0b9 in MORMOT.CORE.JSON_$$_init$ () at ../../mORMot2/src/core/mormot.core.json.pas:11691
#7  0x0000000000421792 in fpc_initializeunits ()
#8  0x0000000000403cdf in main () at SOneSrv2.dpr:550

Same behavior as under FreeBSD.
The AV occurs after unlocking a CriticalSection. I don't think it has to do with an old libc, but with using libthr (instead of libpthread under linux).
I guess it's not an Docker issue rather than an issue of the using image.

I'm not able to find a solution atm. The only thing I've found is the initialization of the CS will be called serveral time in right same thread (the thread of the initialization of the units.
Perhaps the libthr releases a CS when it will be initialized a second time. But it's just a guess.

Thanks for your hint (after reading I remember).
After patching ncal.pas it just works with 3.2.2 under freebsd!

Are you using 32-bit? Postgres14 comes only with a 64-bit client

Yes, this is could be useful in case of big inserts, I guess.

Ok, thanks, that sounds better.

I understand your statements totally and I agree with them, but just some thoughts:

1.  also I use your aggregate call it doesn't get the rights count documents. There reply count are 101/34398/16795 (if no BatchSize is set).
But in SendAndGetRepliesAndFree Opaque will override every time OnEachReply is called. Here is the issue!

2. the first 101 batch is just for analyzing of the optimal batch count and I trust the algo at server side here. Because every document could have a special size I don't know the optimal BatchSize of my own database.
The second call brings than 38.000 and the last one 16.000. So there is not so much to optimize. If the batches are to large, than in a client-server architecture with many clients, the first client gets his reply some ms faster, but at costs of waiting all others.

Sure I'll try it.

But do you want to say, RunCommand isn't supported from mORMot2 any more (after rewriting)? Although all was still working in commit dc66841?

You are right. I had to remove all my $db params.
Sorry for that.

Hello Arnaud,

thanks for implementing new wire protocol. I'm testing your commit and it looks promising.

Daniel

Some changes are necessary e.g. replacement of CursorID (not available in > 3.6).
I will send you an other version of mormot.db.nosql.mongodb.pas as soon as I've fixed last errors on my side.

Hi Arnaud,

after making some PRs further changes are necessary to work with new WIRE protocol.
But creating PRs with GitHub is too painful.
If you want, I can send you my version of mormot.db.nosql.mongodb.pas.

Atm my service starts with auth + ssl, list collections and check indexes and insert an array of documents. And all other stuff looks good from my side, because we only used RunCommand and inserting new $db field is the only change we have to do at our side.

Daniel

The header is always empty (='').

In mormot.net.sock line 3442 F.BufPtr has following value:

'HTTP/1.1 200 OK'#$D#$A'X-Powered-By: mORMot 1.18 synopse.info'#$D#$A'Server: mORMot (Windows)'#$D#$A'Content-Length: 0'#$D#$A'Content-Type: application/json; charset=UTF-8'#$D#$A'Accept-Encoding: synlz,gzip'#$D#$A'Connection: Keep-Alive'#$D#$A#$D#$A'0627055'

and size is 1024 (always).

In error case sock has following value:

($3A8, '127.0.0.1', '8091', '', '', $36EE460, nil, 30000, 91406, 134278, nil, 0, False, nlTcp, 'PUT /LogService/RemoteLog HTTP/1.1'#$D#$A'Host: 127.0.0.1:8091'#$D#$A'Accept: */*'#$D#$A'User-Agent: Mozilla/5.0 (Win; mORMot 2.0.3606 HCS)'#$D#$A'Keep-Alive: 20000'#$D#$A'Connection: Keep-Alive'#$D#$A'Content-Length: 24'#$D#$A'Content-Type: application/json; charset=UTF-8'#$D#$A#$D#$A'20220711 07315309  +    '#9'02.498.812'#$D#$A'20220711 07303732  -    02.498.840Answer Interface=200 out=15 B in 2.49s'#$D#$A'20220711 07303732 ret   '#9#9'mormot.rest.server.TRestServerRoutingRest(0a167520) {"result":[[]]}swer in=75 B'#$D#$A'20220711 07303501 call  '#9#9'uRestServerDB.TSOneRestServerDB(03028dd0) IIntranet.PollWebRTCAnswer{"Params":{"user":"daniel","accesskey":"fc4eb1e37cf603a315a40e13e533c3a6"}} ENetSock {Message:"THttpClientSocket.SockRecvLn error 10053 after 0 chars"} [TRemoteLog LogService] at 6ac915  '#$D#$A'20220711 07241519 srvr  '#9#9' 192.168.1.214 POST root/Intranet.PollWebRTCAnswer Interface=200 out=15 B in 23.03s'#$D#$A'20220711 07241519 ret   '#9#9'mormot.rest.server.TRestServerRoutingRest(0a167520) {"result":[[]]}'#$D#$A'20220711 07241519  -    '#9'23.037.594'#$D#$A'20220711 07241519  -    23.037.624cf603a315a40e13e533c3a6"}}'#$D#$A'20220711 06555037 srvr  '#9#9' 192.168.1.214 POST root/Intranet.PollWebRTCAnswer Interface=200 out=15 B in 4.81ms'#$D#$A'20220711 06555037 ret   '#9#9'mormot.rest.server.TRestServerRoutingRest(0a1670a0) {"result":[[]]}'#$D#$A'20220711 06555037  -    '#9'00.004.826'#$D#$A'20220711 06555037  -    00.004.851'#$D#$A'20220711 06562747 EXC   ENetSock {Message:"THttpClientSocket.SockRecvLn error 10053 after 0 chars"} [TRemoteLog LogService] at 6ac915  [TRemoteLog LogService] at 6ac915  0220711 06512160  -    '#9'00.654.069'#$D#$A'20220711 06512160  -    00.654.089'#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0

In such cases len = -1 (line 1858 mormot.net.sock)

Perhaps it has nothing to do with updates of mORMot2, but with the body of my request. But I don't know how to get it.

Thanks!

I've tested your changes and it works in my project without issues.

Ctxt.OutContent is perfectly identical (mORMot1 vs. mORMot2)! Not what I expected.

Seems to be a wrong content-length in http header. How can I check this value? In Ctxt I haven't found it?

As a side note, content won't parsed under mORMot2 by

_Json(JSON, Result, [dvoReturnNullForUnknownProperty, dvoAllowDoubleValue, dvoValueCopiedByReference]);
--> var JSON: RawUTF8, Result: Variant)

whereas under mORMot1 it will.

at Service level Result is ok, in Http.Request Ctxt.OutContent is wrong often (not always).
Although length of Ctxt.OutContent is correct, you can't convert Ctxt.OutContent to _JSON (json is invalid here).

With mORMot1 length is the same as under mORMot2, but you can convert Ctxt.OutContent to _JSON without error.

In TBaseWriter.AddNoJsonEscape P can't parsed to json with _Json (TDocVariantData(Value).InitJson(Json, Options) gives false), but P parsed with JSON-Lint says "valid json"

I've to compare the P (mORMot1<>2) tomorrow.