Copy link to clipboard
Copied
Hello,
I confirm the writings of kristian54, links download the 12.0.0.31 version.
Thank you in advance for corrections.
PS : Already during the last beta (from 12.0.0.24 to 12.0.0.31) it was very long to get the right version.
Before I got the correct version on the online.
Kind regards.
It's OK now on 23 December at 14:15
The downloading is done well on the 12.0.0.39 version.
Copy link to clipboard
Copied
It is now 2 days that the 12.0.0.39 release and links always refer to the 12.0.0.31 version. : http://labs.adobe.com/downloads/flashplayer.html
Before, for other beta, it worked properly.
Please bring the necessary correction.
Thank you
Copy link to clipboard
Copied
I have to confirm another 3 days later that the all downloaded 12.0 beta files still wear version 12.0.0.31.
Example:
I guess we can forget it to get a proper release in this year 2013...
Unbelieveable incompetence.
Copy link to clipboard
Copied
It's OK now on 23 December at 14:15
The downloading is done well on the 12.0.0.39 version.
Copy link to clipboard
Copied
Thanks for the confirmation. There are ~130k distribution nodes (edge servers) distributed geographically around the globe. It seems like one or more nodes was not updating as expected. We test every build we post from a couple globally distributed offices, but that's only a small sample of the possibile end-points that you could be routed to depending on your geographic and network topologies.
Each node is supposed to automatically refresh it's content whenever we push, and each time the node's cache expires (which is relatively frequent). We can only see aggregates (I don't even see a dent in the typical traffic for this time range) and not statistics on individual nodes). Initially, I figured that the stuck node missed the update notification, but would pick up the change when it's cache expired (this is how it works 90% of the time) -- but it seems like neither of those mechanisms were working correctly in this instance. We manually invalidated all caches on the CDN nodes and it seems to have resolved the issue.
We'll be following up with our CDN vendor to let them know that this has been a problem, but it may be difficult to solve without a statistically significant set of data about where people were seeing the problem. We'll continue to keep an eye on it, and detailed reports about when and where you see download problems in the future will be very helpful in compiling and sharing the information with our vendor so that they can try and narrow it down. They operate something in the neighborhood of of 137k edge-nodes and process more than one trillion daily requests.
Calling up with "hey, one guy in an indeterminate location didn't get the download" isn't going to effect a resolution, whereas "I've got 50 reports from users in Nice, France that they're consistently hitting stale content" would be enough data that they could probably start to pin it down -- or at least narrow it down to a pool of several hundred possible machines.
Anyway, thanks again for your polite feedback and confirmation!