gecomail wrote:
but i think that "latency" is most used replication to justify a lot of problem that i have meet in rsWeb.
Latency/bandwidth is the most likely reason why a large data transfer that works over LAN would fail over WAN/Internet.
Quote:
but i think/believe that webApp must no lock/stall if the operation (like retrive some records) employ long time...
Breaking tasks down into pieces to avoid locking up the UI, desktop or web, is not something the compiler can automatically do for you. You have to look at your code and decide how to do that. In this case it's pretty easy. Do one or both of the following:
* Display subgroups of records, say 100 per group, and give the user some way to navigate the groups.
* Load the WebListBox using a WebTimer.
BTW, I would bet the WE app is not locking up, which you can test by opening another connection in a separate browser. The browser itself (or browser window/tab) is likely locked while waiting to receive data and complete its work. JavaScript is not multithreaded.
Quote:
I think that when %CPU is hight the webApp can be slowed (like locked) but when %CPU back to normal level (in this case the sub that retrieve records and fill webListBox has terminate his execution) the webApp must come back to respond and not result locked/stalled.
Just because the web app's CPU usage has dropped doesn't mean that the network transfer is complete, the client side JavaScript execution is complete, or that the browser's HTML rendering is complete.
Quote:
the latency must no lock/stall my webApp.!!!
WAN speeds are a fraction of LAN speeds, and the client side framework can't do much until it has all of the data.
Quote:
Then i can create code for manage this problem but this is not a recognized/documented problem of rsWeb edition...
It's a recognized problem for all web languages. If you were using something else, say straight PHP and JavaScript, you would have to take similar steps.