Failed to correctly receive server response

[Brian Sayatovic]

I'm trying my first hand at integrating EQATEC into my Silverlight application.  I'm not seeing any data in the dashboard.  I can see the monitor starting when I attach an ILoggerInterface:

    IAnalyticsMonitor.Start: monitor started

However, any attempt to track/time a feature logs an error and then a message:

    Failed to correctly receive server response: 
    Statistics failed to be sent: Failed to correctly receive server response: 

Using Fiddler, I see an initial connection to your servers to fetch clientaccesspolicy.xml, but then no subsequent requests while my app is running and trying to track features (but encountering those errors).

Any advice?

[Admin]

Hi Brian,

You've started out troubleshooting this issue really well, and what you're doing should "just work".

I have examined the error logs on our server and there has been no error in processing incoming data for your product key, but also no data has been received. So it really does seem as if data doesn't make it to our server.

It's somewhat puzzling that no further requests are being made after the (mandatory) request for clientaccesspolicy.xml. However, I can see that at least for SL3 there were some caching-issues; see http://stackoverflow.com/questions/5044402/requesting-for-a-clientaccesspolicy-file-in-silverlight-3. Does this apply to you, maybe? What happens if you run your SL app in another browser or in a private session - does that work differently?

Could you possibly capture all the eqatec-related Fiddler output from the app and share with me? Both the clientaccesspolicy.xml request and any subsequent requests-attempts, if any (though you see none now). If they are too big to post here you are welcome to email me directly at [e-mail] and I'll answer in this thread.

best regards,
Richard Flamsholt

[Brian Sayatovic]

I tracked it down to a System.Security.SecurityException where the EQATEC MessageSender is making it's web requests back to EQATEC.  I believe my clientaccesspolicy.xml is blocking it's attempts:

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="SOAPAction">
        <domain uri="http://*"/>
        <domain uri="https://*" />
      </allow-from>
      <grant-to>
        <resource include-subpaths="true" path="/"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

I need to expand this to allow the client to contact EQATEC as well, but I want to do it in the narrowest way possible.  Maybe this is in your documentation, so I'll go back and look.

[Brian Sayatovic]

To further clarify, it is indeed the connection back to the EQATEC URI that's being blocked.  Here's the (with my product key masked):

https://MYPRODUCTKEY.monitor-eqatec.com/monitor.ashx?pv=4&mt=dotnetsl&mb=3.2.1&cv=&av=14.0&pi=MYPRODUCTKEY&ms=0&rs=0&tm=1

[Richard Flamsholt]

Hi Brian,

I may have a solution for you.

Your scenario is an http-loaded Silverlight app that connects to our service using https. This cross-domain and cross-protocol stuff is tricky business, but it's possible that our server is serving an inadequate clientaccesspolicy.xml in that scenario. See for instance http://timheuer.com/blog/archive/2008/10/14/calling-secure-services-with-silverlight-2-ssl-https.aspx

We have made modifications to the policy-file so it now doesn't use the uri="*" approach but rather explicitly specify access for http and https. There are reports on the web about this having a positive effect. Could you try again and see if our change has solved the issue?

Regards,
Richard Flamsholt
Telerik

[Brian Sayatovic]

Richard, thank you, I think that may have done it.  Fiddler now shows requests to the URI which previously was being blocked (e.g. "/monitor.ashx?...").  I don't yet see any data in my dashboad, but my understanding is that there is some lag between when data is transmitted to EQATEC and when it has been digested and ready for viewing in the dashboard (suggestion: some sort of instant gratification would be a very good hook for new users).  Can you confirm from your side whether you see analytic data coming from my application?

[Richard Flamsholt]

Hi Brian,

In fact you are already getting data through, I can see. We're working on improving the initial-data scenario because it really is very important but data can always be about 5 minutes delayed throughout our backend.
 
Right now there are a couple of ways you can see the live data:

1) Enabling "live" mode in the lower right corner will show last 3 days of data, including today
2) The "Live" report (under Developer Reports) show all incoming data sessions

But wait! The Live report shows that data has been pouring in? Why isn't it being displayed?! What happens is a bit subtle: the incoming data has been marked "internal" and is therefore by default not shown in the dashobard. There's no indicator that internal data exists, but try clicking the Origin-filter below the period slider and select something else than Public and you'll see this internal data.
Data is marked internal in two ways: either by configuration on the Analytics client, by marking for a product a specific IP or released version as producing internal data, or by setting the TestMode-flag in the monitor, which will flag this particular monitor instance's data as internal regardless of IP or version. Since you don't have an IP or version filter in play, my guess is that you have set the TestMode flag to true in the monitor. And that's why data is by default being hidden. Am I right?

We're working on making this scenario more visible in the upcoming release of our Analytics client, because users (and even ourselves) are sometimes tricked by this and ask "where's my data?", when in fact it has just been hidden by the default filtering.

Regards,
Richard Flamsholt
Telerik

[Brian Sayatovic]

Thank you again, Richard.

I didn't realize the lag was only 5 minutes.  That is quite reasonable!  In fact, a few minutes after I sent my reply, I started seeing my data.

And, yes, it is marked as internal.  This version of our build is still an internal build for development and QA purposes.  When it goes RTM, we will flip that.  When you guys explained that feature to us in a demo, I immediately knew I wanted to leverage it in this way and I'm very happy about it.

So my data is flowing, and I can see it in the dashboard... now we just need to figure out *what* we want to monitor and analyze!

Thanks for all of your help.

[Richard Flamsholt]

Hi Brian,

Glad to hear that.

You'll might find our whitepapers useful for getting started. They have some very concrete advise about feature naming, how to use analytics to improve usablity of your application, do exception reporting, etc. You can find them here:

http://www.telerik.com/analytics/resources/whitepapers

Regards,
Richard Flamsholt
Telerik