Failed to download chart Timeout - data file is never requested from the webserver.

[Marcus S]

I've had a problem with the interactive .Net chart on many different customer sites, whereby users intermittently see the the message "Failed to download chart - Timeout".  I've seen it mentioned on this forum several times, but never successfully resolved. Doing a bit more investigation, I've found that the problem seems to be coming from the client or network side, not the webserver. 

 

In the IIS logs we are seeing a message like:

2007-06-14 06:34:45 W3SVC1 XXX.XXX.XXX.XXX GET /chartfx62/download/ChartFX.MainClient.DLL - 80 - XXX.XXX.XXX.XXX 200 0 64

Which would normally be followed by a request for the data file, eg /chartfx62/temp/CFT0614_0234452FD69.chw, however on occasions there no log entry for that file.

 

It appears intermittently, the server does not recieve the request for the .chw data file - which says to me that either the .Net client is not requesting it, or the network has dropped the request.  It seems very unlikely to me that we would have identical network problems on multiple sites with no common infrastructure.

Is anyone (or support) able to shed some light on this problem?

 

[Frank]

We are unable to replicate this problem.

1) Can it be a permissions problem. Are these clients configured correctly so that the .NET Client Control can run. Try assigning Full-Trust to the chart. Any changes?

2) Did you checked that the url: /chartfx62/temp/CFT0614_0234452FD69.chw is in fact there?

[Marcus S]

1) I dont think this is a permissions issue - the .Net control loads and runs, it just intermittently fails to download the .chw data file.  The same clients can often render the charts successfully.

2) The url: /chartfx62/temp/CFT0614_0234452FD69.chw is definitely there.  The webserver logs however show that the file was never requested by the client.  This *could* be a [problem with the IIS6 webserver or site proxies, however I would think a problem with those would also manifest in other noticable ways.

 

I realise this would be difficult to reproduce, however I have seen this across many of my clients and wondered if other users have too. It's causing quite a few problems for my company and we may have to drop ChartFX as a result.

 

Even if your developers are unable to reproduce the problem, I think there could be improvements made to the .Net chart client - eg

a) Checking if the TCP connection / HTTP GET request to the server has actually been established

c) Options for retrying for failed chart data downloads

Options for shorter timeouts so that the failure/retry is reported/attempted faster,

d) Options for embedded chart data in the returned HTML so that a separate data request isnt required.

 

 

[JuanC]

a,b and c are all valid suggestions and we will consider them.

d is already implemented, there is a property called EmbeddedData, you can set it on a per-chart basis.

if you have several pages/charts you can set on a per-app basis by adding <EmbeddedData>true</EmbeddedData> to our config file (ChartFX.WebForms.config)

If you have several Web Apps you can set it on a per-machine basis by adding a string RegistryValue named EmbeddedData to HKLM\Software\Software FX, Inc.\ChartFX for .NET\7.0\Server.

Note that the <OBJECT> tag will now include a base-64 string which contains all the settings and data in your chart, this will feel quicker as there will be no need for a second request (and this second request will never fail) but you have to be careful not to do this with charts with large number of points.

JuanC