Rank: Advanced Member
Groups: Member
Joined: 4/6/2015
Posts: 33
|
Observation:
It appears that the EO.WebBrowser.ResourceHandler ProcessRequest method maybe needs a SyncLock if there is a possibility of more than one simultaneous requests.
This is a maybe because it happened last night and not this morning. But I report it anyway...
EO.Total 2019, version 19.1.40.0, Runtime version v2.0.50727. Visual Studio 2017 on Windows Server 2012 via RDP.
Background:
We have an application that runs as a Web application under IIS and also can be wrapped into a WinForms app using EO.WebBrowser.
One of the peculiarities of the app is that the JavaScript gets URLs from several different directory locations, which in deployment will be located under the executable, but in development will be elsewhere on the disk.
We initially handled this with symbolic links and found that to be nuisance. So we changed to segment handlers for IIS and Custom Resources for EO.WebBrowser.
Because the WebView URL also uses the Custom Resource Handler, pretty much all subsequent URLs also go through the Resource Handler. And because the initial web page loads about 20 scripts, the ResourceRequest method gets called simultaneously.
The result was that all scripts went through the ProcessRequest but not all the scripts got loaded. Putting a SyncLock in the ProcessRequest solved the problem.
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Thanks for your feedback. We do not believe the resource handler should automatically apply sync lock. Apply sync lock on the resource handler automatically can unnecessarily creates bottle neck and severely impact performance in some cases. For example, the end user may uses a customer resource handler to handle 11 different sources, when 10 of them comes from local disk and the 11th comes from a remote database over the network. If we automatically apply sync lock then we could unnecessarily create a situation where all 10 local resources got blocked by a single network resource. Without sync lock the 10 local resources would load quickly regardless how long the remote resource takes. So such lock should be handled by the end user if needed just like you did.
|