Data loss

2 posts, 0 answers
  1. Guest
    Guest avatar
    506 posts
    Member since:
    Feb 2012

    Posted 12 Sep 2011 Link to this post

    Hi, I am working on an add-on for an ASP.NET Web Forms application. I do not have access to the global.asax file and cannot track session start and end there. I've been trying to change my code to monitor my add-on at the session level. I have some simple logic that creates and starts the monitor and stores it in the session if it's not already there. The subsequent tracking calls use the monitor from the session if it finds it there. The Close method is never called since I am having a hard time figuring out an alternate solution to track session end. Since I started doing this, I can send logs right after creating and starting the monitor just fine, but all tracking calls made after that, when using the monitor from the session, never seem to make it to your servers. This is very weird. Can you provide any help?
  2. Guest
    Guest avatar
    506 posts
    Member since:
    Feb 2012

    Posted 12 Sep 2011 Link to this post

    Hi Louis 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. Best regards Soren EQATEC Team
Back to Top