Weird wsdl quirk in IE

Question

I've got a list of categories that I display. When the user
selects a category it calls a webservice to fetch the results for
that category, pretty straightforward. We see some odd behavior in
IE when you click the categories in quick succession one after the
other (however I disable the selector after each click until the
result returns so you cant go super click happy, each call takes
1-3 secs to return)...sometimes it returns no results. Its a
totally sporadic error, it probably only occurs once every 20-25
times and we've only been able to produce it in IE (both 6 and 7),
never in FF. I ran fiddler to try to diagnose the problem and
here's what I found.
Each webservice call is by necessity two calls, the discovery
call that fetches the wsdl and the method call where you call your
actual webservice method and get your results back. On the calls
that fail the wsdl call never goes thru which explains why we get
no results. But I'm not getting any errors either, I have an event
handler where I try to trap the error like this:
service.addEventListener( FaultEvent.FAULT, gotoError );
but nothing...this sounds like a flash player issue in
IE...anyone ever experienced this or can an Adobe guru chime in?
thanx

Answer 1

From the plug-in developer guide.. are you doing the following ??
========
To strongly enforce the version update, it is recommended that the applet deployer use the cache_version attribute.
If cache_version is used, applet caching will be updated if the cache_version for the cache_archive is larger than the one stored locally in the applet cache. Note that the version number is used for triggering an update; there is no actual version number attached to the .jar file on the web server. In fact, unless version is used to trigger an update, it is possible the applet on the web server could be updated without the applet in cache_archive.
Using cache_version eliminates the need to connect to the web server to obtain "Modification-Date" and "Content-Length" of the cache_archive. In most cases this will speed up performance.
========