Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Issue with caching and WebGL builds 5.4+

Discussion in 'WebGL' started by ahokinson, Sep 29, 2016.

  1. ahokinson

    ahokinson

    Joined:
    Apr 28, 2016
    Posts:
    22
    I have built my application several times and posted builds on the web, but since updating to Unity 5.4, my builds no longer work.

    I was able to post a clean build earlier which worked, but after updating the files, I am getting the following:

    This happens when I deploy to a web location, and even if I access the files directly from the origin, I am getting the error.

    When attempting a local build using Build & Run, I get the following:

    This happened during the 5.4 beta and I would have expected it to be fixed before being made stable.
    Any advice?
     
  2. alexsuvorov

    alexsuvorov

    Unity Technologies

    Joined:
    Nov 15, 2015
    Posts:
    327
    Hello ahokinson.

    This usually means that the UnityLoader.js version served from your server does not match the version of the .data file, served from the same server. Could you make sure that a fresh new build works well locally (without being uploaded anywhere)?
     
  3. ahokinson

    ahokinson

    Joined:
    Apr 28, 2016
    Posts:
    22
    It does work with the caveat that the second mentioned error occurs.
     
  4. ahokinson

    ahokinson

    Joined:
    Apr 28, 2016
    Posts:
    22
    How might I verify that these documents have the same version? If I can verify it's a caching issue, I can track it down from there.

    Thanks in advance for your help!
     
  5. alexsuvorov

    alexsuvorov

    Unity Technologies

    Joined:
    Nov 15, 2015
    Posts:
    327
    The easiest way to check if this is the issue, is to upload a fresh build to a new folder on your server (folder should have some random name which you have not used before). A new unique folder guarantees that the served files are not cached anywhere. Then open this new url in your browser to see if it makes any difference (I assume that your build works well when you run it from your local drive).
    If this does not help, feel free to share your build url (here or privately).
     
  6. ahokinson

    ahokinson

    Joined:
    Apr 28, 2016
    Posts:
    22
    Truth be told, this project is for a client whose entire business is based on smart caching. I should really have figured caching was an issue with them and not with Unity. I still get the error:

    every time that I Build & Run locally, but if I click past it, it doesn't affect the uploaded version.

    Thanks for your help!
     
  7. ahokinson

    ahokinson

    Joined:
    Apr 28, 2016
    Posts:
    22
    @alexsuvorov

    I'm resurrecting this.

    We turned off all caching and can verify that there is no caching happening. I am still receiving this error:

    And when run locally, I receive the following error:

    You can reproduce the issue at this URL:

    http://tech.akamai.com/attack-globe/nightly/WebGL/

    What else could this be? This seems to be an issue with 5.4. I am tempted to upgrade to 5.5b to see if that fixes the issue...
     
  8. alexsuvorov

    alexsuvorov

    Unity Technologies

    Joined:
    Nov 15, 2015
    Posts:
    327
    Hello ahokinson.
    There is indeed a caching issue involved (or some files have not been updated on the server properly).
    As you can see, your UnityLoader (http://tech.akamai.com/attack-globe/nightly/WebGL/Release/UnityLoader.js) expects a .data file of length 15350559, while the hosted file (http://tech.akamai.com/attack-globe/nightly/WebGL/Release/WebGL.data) is of size 15350877, which clearly indicates that those files are from different builds (i.e. if you download those files to your local drive manually, the local build wont run).
     
    Last edited: Oct 14, 2016
  9. ahokinson

    ahokinson

    Joined:
    Apr 28, 2016
    Posts:
    22
    http://tech.akamai.com/attack-globe/nightly/CompletelyNewWebGL/

    I guess you're right...

    This is a brand new folder and it seems to be working. I guess for now, this will be my workaround. Could you just briefly explain where you got those numbers from so I can investigate this further?

    P.S. Really appreciate your help.
     
  10. alexsuvorov

    alexsuvorov

    Unity Technologies

    Joined:
    Nov 15, 2015
    Posts:
    327
    Normally it is sufficient to manually download the file in question though the browser address bar and compare it with its local version. But if you don't have the original version, you can still tell with very high probability if the files come from the same build by comparing the .data offsets, which are hardcoded in the UnityLoader.js, and should look something like this for release build (somewhere near the end of the UnityLoader.js):
    Code (JavaScript):
    1. ... new t(0,11128554,0,0).open("GET","/data.unity3d"),new t(11128554,11128573,0,0).open("GET","/methods_pointedto_by_uievents.xml"),new t(11128573,11156154,0,0).open("GET","/preserved_derived_types.xml"),new t(11156154,14447962,0,0).open("GET","/Il2CppData/Metadata/global-metadata.dat"),new t(14447962,15322934,0,0).open("GET","/Resources/unity_default_resources"),new t(15322934,15350559,0,0).open("GET","/Managed/mono/2.0/machine.config") ...
    the 2 numbers specify offsets of the beginning and the end of the embedded file, while the very last offset should normally match the the end of the .data file, therefore should be normally the same as the uncompressed .data size (15350559 in your case). The uncompressed size of the .data file can be determined by simply decompressing it (it is a usual .gz archive).
    In case of UnityLoader.js vs .data version mismatch you will most likely get the following error:
    Uncaught Assertion failed: s_GlobalMetadataHeader->sanity == 0xFAB11BAF
    as the embedded metadata file will most probably have a wrong offset.
     
    Last edited: Oct 14, 2016