1
Vote

Race conditions

description

As assemblies and settings are loaded independently and asynchronously, the race condition occurs - if the settings file is loaded before the assemblies, then the engine can not resolve the names of custom link or node views, and a default view is used instead. This is a really anoying and hard-to-track bug.
 
My proposal is to make a staged loading process- assemblies first, then settings and then initial data

comments

Tourpe wrote May 29, 2010 at 4:17 PM

That clearly explains some of the weird behaviors we're seeing. Thanks! We will need to apply your suggestion in the next release (or better yet: help us work on the next release! :))

cwford wrote Jun 24, 2010 at 11:25 PM

Thanks for tracking this 'race condition' down. I'am having problems with ICE being unable to resolve name of custom node views. Is there a temporary workaround for this while waiting for the developers to fix the problem?


Thanks,
Clyde

cwford wrote Jun 25, 2010 at 11:40 PM

I really needed to use ICE for a project, so I spent some time trying to find a workaround for the asynchronous loading problem. My solution is definitely NOT elegant, but it does work:

FOR ASSEMBLIES:
  1. I downloaded the source code for ICE and created a VS2010 project
  2. I added a reference to my library DLL in the ICE project, this way it was included in the XAP after compile
  3. I retrieved a reference to that DLL through System.Windows.Resources.StreamResourceInfo
  4. This meant I had a stream that I got synchronously and could pass the stream to the AssemblyFileLoaded routine in the FileManager class
  5. You can do this for any assembly you wish to read synchronously
FOR XML settings files:
  1. Placed them in my downloaded ICE project
  2. I loaded them in the order I wanted using XmlReader
  3. I passed the XDocument I got from the reader the ICEXmlSettingFile also in the FileManager class
I loaded both the assemblies and the settings files prior to the start of asynchronous loading in FileManager. Now, in my HTML instantiation of the Silverlight object, all I include are the initial data nodes. All of the other files are loaded prior to async loading of the node files.

TRADE-OFFS:
  1. I have to recompile ICE whenever I change my settings
  2. The ICE file is slightly larger because of placing the assembly DLLs there
But my setting files have rarely changed once I found the settings that I wanted and the XAP file is not that large.

I know there are better solutions to this problem and I hope the ICE developers will consider them in a next release but I thought these ideas on a workaround would help someone else. The root cause of the problem is that Silverlight only allows for asynchronous WebClient calls, hence it is impossible to control what is loaded first and often nodes are loaded before settings and things get pretty screwed up.

Again, my thanks to the ICE team for a good project and one I hope continues to grow.

Clyde

cwford wrote Jun 26, 2010 at 3:54 PM

MUCH BETTER SOLUTION

The solution I proposed had some problems on further testing, so I bit the bullet and worked on a better one. Finally decided on this approached, which worked:
  1. Use nomal initParams when instantiating the Silverlight object
  2. In FileManager.cs redo the Start method
  3. Split up the activeLoaders list into three lists: (a) Assemblies list; (b) Settings list; (c) Data nodes list
  4. Call the StartLoading method on each list in order
  5. Set cascading timers to check for when the assemblies and settings lists have been loaded
  6. Only after these lists are loaded, then load the data nodes list as normal
Tested this approach out and it seems to work just fine.

Clyde

wrote Feb 13, 2013 at 10:20 PM