Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6672788

REGRESSION: javawebstart can not handle high latency network

    Details

    • Subcomponent:
    • Introduced In Version:
      6
    • Resolved In Build:
      b22
    • CPU:
      x86
    • OS:
      windows_xp
    • Verification:
      Verified

      Backports

        Description

        J2SE Version (please include all output from java -version flag):
         java version "1.6.0_10-ea"
         Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b12)
         Java HotSpot(TM) Client VM (build 11.0-b11, mixed mode, sharing)

        Does this problem occur on J2SE 1.4.x or 5.0.x ? Yes / No (pick one)
          No

        Operating System Configuration Information (be specific):
          Windows XP PRO SP2
          IE 7.0

        Hardware Configuration Information (be specific):
          Sony VAIO laptop 2.8 Gz
          1.25 GB RAM


        Bug Description:
        Tested consumer JRE version of webstart and there are still big problems with
        webstart. The downloads are still done incorrectly.

        You will notice the critical race condition here that breaks on of the fundamental requirements of webstart...launching an application.

        As it is currently, unpredictable java Errors can occur at runtime (like NoSuchMethodErrors) which should never happen. When got these Errors, it is because
        webstart is running applications with different incompatible libraries. The
        libaries on the server are always compatible, but the downloading of them is
        not consistent and therefore old and new libraries are mixed....sometimes with
        terrible results.

        Restarting the application will cause the webstart cache to re-sync itself
        (thank goodness for this), and the problem *invariably* goes away. To restate
        this: The first time the application is started after a a library update often
        does not work. The second time *always* works.

        What seems to happen is this:
        * Transactions are created to check the timestamps on the cached files.
        * If this is not fast enough, the application will start anyway...leaving the
        downloads to occur after the application has started.

        This would fully explain bug 6632928 in which the certificate dialog comes up 30
        times...and it is ok to cancel almost all of them. It comes up for each time it
        is trying to test/downloaded a jar file. The application should be waiting for this
        process to complete. However, since the application starts anyway, it can try to
        run off of the older libraries that exist in the cache.

        ----Important design note ---------
        When using certificate authentication, starting a thread to simulatiously check each
        cache entry is undesireable since, if the process requires user intervention, they
        will get prompted many times. (User intervention could be necessary because of
        multiple certificates, or because the certificate is on a device that requires
        authentication.)

        Steps to Reproduce (be specific):

        In your download servlet; in the JNLPDownloadServlet, change the sendRespond method
        of DownloadResponse.java to sleep for 5 seconds before it starts to transfer to data.
        This will simulate a high latency network. Also, make sure your test case has several
        jar files. (I am not using versioned jar files and all the jar-diff stuff.)

        Now, download and run the app. If this is the first time, everything will work fine,
        although because of the 5 second sleep, things will take a long time to download.

        Now exit the app and then touch all your jar files (by touch, I mean the unix 'touch'
        to update the timestamps)

        Launch the application again. It will come up immediately, which should not be the
        case since it should be downloading the new jar files

        Now, however, even with the application started, webstart will continue to download
        the jar files. Checking the timestamps of the webstart cache entries validates the
        assertion that jar files are being updated after the application has started.

        **Repeat: Even after my application has started, cache entries are being updated!**

        Remember that the application has started. In this test we just touched the files,
        but in production, these jar files might be quite different than the ones there are
        replacing. If methods are ever changed or removed, this will cause runtime Java Errors
        that should never happen.

        The download also seems to cause the application to suspend for a while. I don't know
        if the downloads freeze the class loader for a while or something. My application
        will just freeze for a few minutes (persumably during the downloading) and then
        continue where it left off. Duing this time the user has no idea what is happening.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  ngthomas Thomas Ng (Inactive)
                  Reporter:
                  tyao Ting-Yun Ingrid Yao (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: