2013-07-24
2013-07-24. Pascal Programming
I'm currently fighting against out of memory errors on an heavy-loaded Java server.
If only it had been implemented in Delphi and mORMot!
But at this time, the mORMot was still in its burrow. 
Copy-On-Write and a good heap manager can do wonders of stability.
Here are some thoughts about Garbage Collector, and how to temper
their limitations.
They may apply to both the JVM and the .Net runtime, by the way.
2013-07-04
2013-07-04. Open Source › mORMot Framework
In mORmot applications, all the client communication is executed by
default in the current thread, i.e. the main thread for a typical GUI
application.
This may become an issue in some reported
environments.
Since all communication is performed in blocking mode, if the
remote request takes long to process (due to a bad/slow network, or a long
server-side action), the application may become unresponsive, from the end-user
experience.
Even Windows may be complaining about a "non responsive application",
and may propose to kill the process, which is far away from an expected
behavior.
In order to properly interacts with the user, a OnIdle property
has been defined in TSQLRestClientURI, and will change the way
communication is handled.
If a callback event is defined, all client communication will be processed in a
background thread, and the current thread (probably the main UI thread) will
wait for the request to be performed in the background, running the
OnIdle callback in loop in the while.
