Posted 12 Sep 2011
Link to this post
I have a few questions and suggestions in regards to your scenario that I hope will help you along:
1) One suggestion is to hook into the internal logging of the monitor to try to get a feel for what is going on and if errors are being reported. You can hook into the internal logging by creating your own implementation of the ILogAnalyticsMonitor interface and assign it to the LoggingInterface property of the AnalyticsMonitorSettings object that you can use to create your individual monitor instances. The internal logging will raise error messages for internal errors and also raise messages each time data is delivered to the server. Hooking into the logging is probably the easiest way to try to determine if something is wrong
2) In regards to your specific scenario, I think that the lack of data delivery may be caused by how the internals of the monitor determines to send data. The internal convention in the analytics monitor is to send data when the monitor is started, when it is stopped and when it is called with "urgent" data. By urgent data we mean data that should be delivered quickly to the servers and we have tagged exceptions and log messages as urgent data. If you only track feature usage and never stop the monitor, the monitor will not trigger an internal send of the data and the data is only persisted to disk once every minute. You can use the ForceSync call to instruct the monitor to schedule data delivery to the servers, I would suggest to implement some timing algorithm that calls the ForceSync method on each monitor e.g. once every 5 minutes to have the "non-urgent" data delivered to the servers.
3) Further to your scenario, I think that the persisting of data may also be a problem. By default the monitor picks a place in Isolated Storage and persists the datamodel. The file name is based on your product key. If you start multiple instances of the monitor with the same product key within the same process, they will all attempt to persist to the same file. This will likely cause inconsistent data to be stored and retreived and may be a further explanation to your lack of data. To eliviate this issue, your can create your own implementation of the IStorage interface and assign to the StorageInterface. The IStorage interface is responsible for storing a byte-array for a specific product key, but if you create an implementation that e.g. takes the session identifier in the constructor and uses that to create a unique filename, there should be no conflicts in reading/writing data.
I hope the suggestions will help you. If you are still stuck, please contact us for further assistance.
A final note on your scenario. We have had a few requests and suggestions with regards to hosting the monitor in an ASP.NET environment. Our current monitor is primarily designed to be "one monitor/productkey per process" which is the scenario in most standard applications on PCs and mobile devices. We realize that the monitor is not perfectly suited to the "multiple monitors per process" scenario that ASP.NET is bringing. We are internally in the process of determining how we best cover this scenario with respects to internal monitor resource management and consistency in the API. If you have any feedback or suggestions we would be very happy to hear from you.