#1 mORMot 1 » Breaking changes in the latest mORMot » 2018-07-17 11:26:50

ssoftpro
Replies: 2

Dear Arno
When we updated to the latest commit, we encountered some breaking changes introduced:
1) TCrtSock.SockSendFlush procedure requires to set "body" parameter now. This does not correspond to the description of this function where this parameter described as optional. Should the function declaration be changed in the way body parameter has a default value of an empty string?
2) SetRawUTF8 function disappeared. Should we use FastSetString instead or what is your recommendations on the replacement?

#2 Re: mORMot 1 » Windows authentication on the server » 2018-06-10 15:25:04

Hi, Chaa

MPV is too busy right now with other tasks so asked me to verify your patch in our environment.
Everything works fine!
The only thought worth to mention is a conversion between Kerberos username and NT username is not as easy in common case. For example, I've seen a domain where NT style name was ABCCORP, while the canonical name - CORP.ABC.COM.UA. I suppose it is hard to automatically convert names, so it could be useful to introduce some "dictionary" and register name pairs while bootstrapping.

#3 Re: mORMot 1 » Problem migrating THttpApiServer -> THttpServer » 2018-01-28 14:50:03

On my side was a check of contention parameters calculation and I've found that it is needed to add 'tix := GetTickCount;' assignment immediately after SleepHiRes block. Otherwise, the last loop before a successful fThreadPoolPush call is not counted in fThreadPoolContentionTime.
Removing 'break' after a successful fThreadPoolPush call is not an alternative because we should not include the time spent on the fThreadPoolPush call itself.

#4 Re: mORMot 1 » Problem migrating THttpApiServer -> THttpServer » 2018-01-27 11:24:58

And one more thing - it could be handy to get back ThreadPoolContentionCount property but increase it only once - just before the repeat loop starts. This would allow average contention delay calculation dividing ThreadPoolContentionTime by ThreadPoolContentionCount

#5 Re: mORMot 1 » Problem migrating THttpApiServer -> THttpServer » 2018-01-27 10:46:53

Dear @ab!

Thanks a lot for the latest changes and sorry for broke some other parts of the framework.
I'm currently trying to wrap up all the things and found that you missed ThreadPoolContentionAbortDelay property initialization. And currently this is a read-only property, should it be writable, what do you think?

#6 Free Pascal Compiler » Use of FastMM4 causes a bug in SetLength » 2018-01-07 15:43:07

ssoftpro
Replies: 2

While compiling mORMot with the latest master version of FastMM4 on Linux 64 bit using either FPC 3.0.4 or 3.3.1 I'd encountered a strange error: when writing large (~50K) buffers into TRawByteStringStream, the content of the internal string became corrupt after on 6-7th write. This depends on the size of the buffer written and reproducible for buffers 45, 50, 55Kb in length. In addition, I've discovered that it is enough to temporarily save a pointer to the internal string in TRawByteStringStream.Write to eliminate this error. I assume this is because FastMM releases memory too early when a string is enlarged. In order to prevent any influence I've created a synthetic test and got the same error.

#7 Re: mORMot 1 » Can't debug on FPC as win64 target because of crc32c64.obj » 2017-11-14 13:41:35

Hi, ab! I've managed to strip debug information from crc32c64.obj and this allows me to compile and debug using fpc in Win64 without problems. Where would it be better to put the file with debug info stripped? should I place it in the fpc-win64 folder or it is better to just replace the current version of crc32c64.obj?

Board footer

Powered by FluxBB