11-30-2023, 11:11 PM
(11-29-2023, 05:24 PM)PabloRomero Wrote: They always exchange XML based structures, like text. In this XML, there is a "command" property. This property receives every 15 minutes the command
"Keep" and the server answers "ok, here I am, Keep ok" and gives to the station that runs my application, status and login information.
15 minutes is a long time to keep a TCP connection sitting idle without any traffic. Some firewalls/routers will close an idle connection after just a few minutes. You might consider closing any TCP connection that is going to be sitting idle for awhile. Otherwise, assuming your "Keep" command is meant for keeping a license alive rather than keeping the TCP connection alive, you might consider sending a separate status/heartbeat command more frequently. Or even enabling TCP-level keep-alives on the connection itself.
(11-29-2023, 05:24 PM)PabloRomero Wrote: All the information is stored in memory in a structure based on Tlist<Types>.
Since you are worried about synchronization, why not use TThreadList<Types> instead? Or at least put a TCriticalSection around your TList (which is what TThreadList does)?
(11-29-2023, 05:24 PM)PabloRomero Wrote: Here comes the problem. My application disconnects randomly, to some workstations. I suspect it must be because of the way I protect the structures and data shared by the threads.
Possibly. TIdTCPServer does not disconnect clients randomly, however if a runtime Exception occurred while accessing your data, that could certainly kill your client threads.
(11-29-2023, 05:24 PM)PabloRomero Wrote: As you can see, "TManejoPaquetesDOM = class(TIdSync)". This is who processes everything. As I understand it, TidSync makes all the other threads of IdTCPServerExecute threads wait for it to finish.
Not exactly. It makes a request to the main UI thread to run the specified object method, blocking the calling thread until that request is finished. So, other calls to TThread.Synchronize()/TIdThread.Synchronize() (and TIdNotify.Notify()/TThread.Queue()) will synchronize with each other. Other threads that are not performing sync requests will be unaffected.
(11-29-2023, 05:24 PM)PabloRomero Wrote: I'm not sure if this is the best approach, ideally the process should be parallel without making anyone wait.
Then don't synchronize your processing. Only synchronize access to shared resources, like your TList, but do the actual processing outside of the syncs.
(11-29-2023, 05:24 PM)PabloRomero Wrote: All the structures when accessed by the other threads of my application are protected with a generic class I made
like this
...
Each time the data shared by threads are accessed, those threads protect the data with an instance of this class, global to the whole service.
Then why are you synchronizing your processing if it is providing its own thread safety?
(11-29-2023, 05:24 PM)PabloRomero Wrote: My problem is that I can't detect those random disconnections of some users from my system.
Are you running your code inside the debugger when the disconnects occur? Are you logging errors (especially in the TIdTCPServer.OnException event)?
(11-29-2023, 05:24 PM)PabloRomero Wrote: a) Is there a way to speed up what IdTCPServerExecute does? Not using TidSync?
There is not enough context to answer that. We don't know what you are syncing and why, or what your processing is actually doing that might be getting bottlenecked.
(11-29-2023, 05:24 PM)PabloRomero Wrote: b) What is the best way to protect shared data between threads? I'm not sure what I did is the best approach.
Again, not enough context to answer that, since we can't see what you are trying to protect exactly.

