Leaderboard

You (as far as i know), need always to create (request for) a new FDConnection with each request, each request runs as it's own thread. At what "ServerConnectionPool data module" you are referring to ? (can not see somehting like this in the template folder? I have examples of how to use the FDConnection in a normal request/resource if you need that. uses MARS.Core.RequestAndResponse.Interfaces, MARS.Data.FireDAC, ..... TMyResource = class strict private protected // connection can be left away, when referring to MAIN_DB in the .ini [Context, Connection('MyDB', False)] FD: TMARSFireDAC; [Context] FRequest : IMARSRequest; public [Produces(TMediaType.APPLICATION_JSON)] function GetInfo([QueryParam('par1')] const APar1: string; const [QueryParam('par2')] APar2 : integer) : TMyInfo; end; function TMyResource.GetInfo(const APar1: string; const APar2: integer): TMyInfo; var fqry : TFDQuery; begin if not FD.Connection.NewQuery(fqry) then raise Exception.Create('Error bij aanmaken van query'); try fqry.sql.text := 'select * from ...........'; fqry.Open(); while not fqry.Eof do begin fqry.Next; ..... end; finally fqry.Free; end; end;

D2Bridge delivers a true “click-to-web” experience for Delphi: just recompile, run, and open the browser—no need to change language, switch IDE, or refactor your business layers. For teams that need to put a VCL system online quickly (whether intranet or SaaS), it shrinks months of migration work down to a few days of fine-tuning. If your goal is a smooth transition, minimal rework, and full continuity of Delphi expertise, D2Bridge is currently one of the most straightforward solutions available.

Hello everyone, I'd like to introduce my first Delphi IDE extension: DripGrepper. DripGrepper uses ripgrep to enable extremely fast searching. Based on my experience, in a ~20 GB repository, it delivers results within 3 seconds—that’s 3 to 5 times faster than the standard Delphi IDE search! If you're interested in a comparison with other search tools, you'll find an overview here. The current release includes both a standalone version and DLLs for: Delphi 11 Delphi 12.1 CE Delphi 12.3 Athen DripGrepper is still in beta, so errors may occur. Nevertheless, it has already become an integral part of my workflow—and I can work productively with it. Last Updates: 14.07.2025 New version with Delphi 12.3 support: v4.9.0-beta 01.07.2025 New version: v4.8.0-beta Tip: Try out the "Open With..." feature via Delphi Tools → DripExtensions → Open With... to open the file you're currently editing: I look forward to your feedback! Screenshots:

Why not simply rename or move (not copy) the original temp file to the new filename, instead of copying its data to a new file? The only way I can see that happening is if you are not sending a response to the client until after the file data has been copied to the final file, and it's taking a long time to do that copy. Clients are not going to wait around forever for a response after they send their data to the server, so you should try to send a response as soon as possible, ie when the data has been saved in the temp file, or once processing of that file has begun in the background. If that is not an option, they you have no control over the client's timeout settings on the server side, so all you can do is optimize your processing to speed it up. If your processing is going to take a long time, then return a response ASAP and then provide a separate API for the client to poll the status of the processing, ie a separate REST endpoint, or a WebSocket, or server push events, etc. That has nothing to do with Indy, but with your OS and/or hard drive performance. Maybe you are writing to bad sectors, or there are other I/Os in progress that slow down the OS's handling of your file, etc. No way to diagnose that from your limited description. Also, TStream.CopyFrom() was pretty basic in 10.3. It was re-written sometime after 10.3 with more buffering logic. Speaking of buffering, consider using TBufferedFileStream instead of a plain TFileStream. TBufferedFileStream was introduced in Delphi 10.1. That way, more of the copying process is done in memory rather than directly on the hard drive. Handling data with file I/O will always be inherently slower than handling data in memory. It didn't. The client timed out and closed the connection on its end. If you are doing your file processing directly in your OnCommand handler then the server CAN'T close its end of the connection until you return control back to the server, ie by exiting the handler. Yes - don't perform long-running processes directly in your OnCommand handler that makes the client wait a long time for a response. No. Especially if different threads are working on different files. There is no timeout you can set on the server side that will affect the client's own timeouts. However, one thing you might try is TCP keepalives, not HTTP keepalives, ie via the AContext.Connection.Socket.Binding.SetKeepAliveValues() method. But, that won't prevent the client from just giving up if no response arrives in a long time.

Test 1: All threads with normal priority Starting test with duration: 3 seconds Thread priorities: Sleep(0)=Normal(0), Sleep(1)=Normal(0), SwitchToThread=Normal(0) Results: Sleep(0) iterations: 3325126 Sleep(1) iterations: 1511 SwitchToThread iterations: 3475552 Test 1.1: All threads with normal priority Starting test with duration: 1 seconds Thread priorities: Sleep(0)=Normal(0), Sleep(1)=Normal(0), SwitchToThread=Normal(0) Results: Sleep(0) iterations: 1113996 Sleep(1) iterations: 504 SwitchToThread iterations: 1164189 Test 1.5: All threads with normal priority Starting test with duration: 5 seconds Thread priorities: Sleep(0)=Normal(0), Sleep(1)=Normal(0), SwitchToThread=Normal(0) Results: Sleep(0) iterations: 5517579 Sleep(1) iterations: 2521 SwitchToThread iterations: 5767000 Test 2: Different priorities Starting test with duration: 5 seconds Thread priorities: Sleep(0)=Higher(1), Sleep(1)=Normal(0), SwitchToThread=Lower(-1) Results: Sleep(0) iterations: 5424269 Sleep(1) iterations: 2517 SwitchToThread iterations: 5672785 Test 3: Different priorities Starting test with duration: 5 seconds Thread priorities: Sleep(0)=Lowest(-2), Sleep(1)=Highest(2), SwitchToThread=Normal(0) Results: Sleep(0) iterations: 5372945 Sleep(1) iterations: 2519 SwitchToThread iterations: 5648329 Test 4: Different priorities Starting test with duration: 5 seconds Thread priorities: Sleep(0)=Lowest(-2), Sleep(1)=Lowest(-2), SwitchToThread=Lowest(-2) Results: Sleep(0) iterations: 5533097 Sleep(1) iterations: 2518 SwitchToThread iterations: 5778718 Done. Starting starvation test with Sleep(0), Consumer=Normal(0), Producer=Normal(0) Result: Sleep(0) time: 0 ms Starting starvation test with Sleep(0), Consumer=Normal(0), Producer=Lower(-1) Result: Sleep(0) time: 0 ms Starting starvation test with Sleep(0), Consumer=Lower(-1), Producer=Normal(0) Result: Sleep(0) time: 0 ms Starting starvation test with Sleep(1), Consumer=Normal(0), Producer=Normal(0) Result: Sleep(1) time: 0 ms Starting starvation test with Sleep(1), Consumer=Normal(0), Producer=Lower(-1) Result: Sleep(1) time: 0 ms Starting starvation test with Sleep(1), Consumer=Lower(-1), Producer=Normal(0) Result: Sleep(1) time: 0 ms Starting starvation test with SwitchToThread, Consumer=Normal(0), Producer=Normal(0) Result: SwitchToThread time: 0 ms Starting starvation test with SwitchToThread, Consumer=Normal(0), Producer=Lower(-1) Result: SwitchToThread time: 0 ms Starting starvation test with SwitchToThread, Consumer=Lower(-1), Producer=Normal(0) Result: SwitchToThread time: 0 ms Done. Intel Core i5-9500 3.00 GHz, Windows 11 Pro 24H2

I'm looking to replace MS ActiveScripting in FinalBuilder.

This is all documented. Obviously we can tell you the answers but once you know about New, you can read the documentation to find out the rest of the details. It's really useful to know how to do that.