You are not logged in.
@ttomas
Ok - Thanks
---Edit---
It failed and generated 9 log files. However, after reviewing the logs, I couldn’t identify the problem.
Last edited by Kabiri (2026-05-01 10:29:59)
Online
Compress the logs in a zip and make a link here.
Log file :
https://mega.nz/file/s5hkBChA#geEYuBua8 … cJDp4KyHhw
Online
You must provide source of init of your server/services and code of your interface using orm/dbparams. For test, what type of http server you use sync/async and how many threads?
From log:
Vi 260430200213 6714 is main init thread all OK
Vi 260430200227 2c24, Vi 260430200228 3ad0 looks like working threads and all is OK, on top you have pg db connection
Vi 260430200601 5cc8 and Vi 260430200702 6658 threads don't have own connection and this is the problem, you use same db connection from different threads!
Look like interface created threads using db connection in wrong way, provide some source for ViTaskService.GetDetail, ViTaskService.ViewTask.
Or you call this methods from different thread!
Last edited by ttomas (2026-05-01 17:44:24)
Offline
message type 0x31 arrived from server while idle
message type 0x32 arrived from server while idle
message type 0x54 arrived from server while idle
message type 0x44 arrived from server while idle
message type 0x43 arrived from server while idle
message type 0x5a arrived from server while idle
in Vi 260430200702 6658 confirm using same connection in multiple threads
Offline
There is also something wrong: "prepare" is done for each statement, which does not make any sense.
They are supposed to be cached and reused.
Please don't use ptOneFilePerThread, but ptIdentifiedInOneFile so that we could easily see using SynLogViewer the parallel process.
How do you setup the connection in your code?
Are you sure you are using ThreadingMode = tmThreadPool for the connection properties?
How are your services setup?
Don't use sicPerThread for your services instance pattern but sicShared.
Also ensure you don't touch the TInterfaceMethodOptions unless you know what you are doing.
Offline
The database connection is set up like this:
{$ifdef DBZeos}
DBProps := TSqlDBZeosConnectionProperties.Create('zdbc:postgresql://' + Host,DBName, DBUser, DBPass);
{$else}
DBProps := TSqlDBPostgresConnectionProperties.Create(Host, DBName, DBUser, DBPass);
{$endif}
DBProps.UseCache := False;
DBProps.ReconnectAfterConnectionError := True;*DBZeos is not being used.
I set ptOneFilePerThread.
I did not change the connection properties threading mode, so it is still using the default value.
As you suggested earlier, I already switched to sicShared. The previous log was also generated with that setting.
I have not changed TInterfaceMethodOptions at all.
For each table, I register it like this:
VirtualTableExternalRegister(Model, TOrmAlarm, DBProps);
And each service is defined like this:
Server.ServiceDefine(TViAlarmService, [IViAlarmService], sicShared);
Inside the services, I only use ORM.
New log : https://mega.nz/file/8k4SUYyQ#f5pgGyFb6 … 7_m5hd2B7s
Look like interface created threads using db connection in wrong way, provide some source for ViTaskService.GetDetail, ViTaskService.ViewTask.
Or you call this methods from different thread!
I implemented the interface the same way as the others. Only ORM is used inside these methods.
ViewTask only receives an ID and performs a simple update.
GetDetail reads values from several tables and puts them into a single JSON object.
Last edited by Kabiri (Yesterday 09:11:48)
Online
The database connection is set up like this:
{$ifdef DBZeos} DBProps := TSqlDBZeosConnectionProperties.Create('zdbc:postgresql://' + Host,DBName, DBUser, DBPass); {$else} DBProps := TSqlDBPostgresConnectionProperties.Create(Host, DBName, DBUser, DBPass); {$endif} DBProps.UseCache := False; DBProps.ReconnectAfterConnectionError := True;
but where?
please share the small "reproducible" sample you made the other day.
while writing this, I'm currently working on a hobby project - a custom RAG system that ingests all the mormot code into a postgre database using the pgvector extension. It uses an async http server, orm, and soa, and I haven't had any issues with many worker threads so far.
Last edited by flydev (Yesterday 09:39:55)
Offline
The structure of this application is exactly the same as the main application. In this application as well, I didn’t encounter any errors, as I mentioned before.
However, this one uses a single table in the endpoints, while the main application uses multiple tables and more complex reports.
Online
It happened in this sample code as well.
I also included the log files in the RAR archive.
Online