Forum Stats

  • 3,768,728 Users
  • 2,252,841 Discussions


Does offline mode only work with background updates?

1034092 Member Posts: 17
edited Jun 19, 2015 8:55AM in Java Web Start & JNLP


I have an Webstart application which should be available in offline mode while users should receive updates in a timely manner. Therefore I added the following to the JNLP file:

    <offline-allowed />
    <shortcut online="false" install="true">
        <desktop />

But when the server is not available or the internet connection is down I always get a FailedDownloadException when launching the application via the shortcut (Ubuntu 14.04; Java 8). The only way to make it work is with background updates:

<update check="background" policy="always"/>

But then it's not very reliable when the user receives the update. In my experience the application has to be open quite some time. It seems also not to be possible to turn off the updates and control them yourself (using DownloadService2 of the JNLP API). I would like the appliocation to fully work offline, but update if the server can be reached, preferably with the check="timeout" setting, which I would expect to work that way. Have I overlooked something or is this just not possible?



  • jlanawalt
    jlanawalt Member Posts: 41
    edited Jun 1, 2015 1:33PM


    We've been deploying some applications via web start for several years that are available in offline mode and where users receive updates in a timely manner (on the next launch when they can connect to the server).

    <offline-allowed /> <!-- Allow the app to launch even if there is no network, to work from cache, will check for updates with timeout -->

    <shortcut online="true"> <!-- Launch the app as javaws -online (the default) so that it checks for updates and BasicService.isOffline() will return true false *-->




    <update check="timeout" policy="always"/> <!-- default as written to cache, we don't specify -->

    It has been our experience that this works as is documented in the JNLP File Syntax [0][3] and the javaws Command Line docs [1].  These settings allow our users to use the software even when offline, but if there is a network connection it will check for updates to the cached files including the jnlp and jar files. If our servers are offline or otherwise unreachable the check times out and the launch continues. If they are reachable and there is an update, it automatically applies the update and continues launching.

    It is my understanding based on docs and posts that using online="false" for the shortcut should keep it from even trying to check for updates [0, offline-allowed element description][2], so I am surprised that offline mode is working for updates at all for you, but I haven't tested this.

    We played with update check="background" but it wasn't a consistent and reliable experience for our use case. I've read of others having trouble with it if their app doesn't stay open long enough [4]. Fortunately for our deployments it was decided that the offline-allowed default of check="timeout" policy="always" was the preferred user and update deployment experience anyway so that's what we've used and not looked back.








    * Edited, meant to say it returns false when online=true.

  • 1034092
    1034092 Member Posts: 17
    edited Jun 1, 2015 12:45PM

    Thank you for your answer. The behaviour you describe is actually exactly what I want to accomplish. For background updates I've had the same (bad) experience, it took 30-60 minutes to update.

    I also tested again the offline shortcut and you're right, updates don't work with <shortcut online="false">.

    Therfore I tried the following configuration:



    <shortcut online="true">




    <update check="timeout" policy="prompt-update"/>


    But this causes the startup to hang indefinitely or at least unreasonably long when I disconnect/disable the network connection. This happend on Linux, Windows 7 (in a VM) and Mac OS using Java 1.8.0_45. The FailedDownloadException might have occured, because the machine was still reachable, but the Tomcat serving the JNLP was down.

  • jlanawalt
    jlanawalt Member Posts: 41
    edited Jun 1, 2015 2:36PM


    I just tested by disabling my network connection and my cached programs launched. A couple I haven't run for a very long time failed saying "cache corruption" and some said "UknownHostException". Launching or failing, the splash screen was up for about six seconds before the error or the application would appear. I'm not sure how the machine was still reachable when you tested by disabling the network interface. Nothing should be reachable in that state.

    I enabled my adapter then put in a firewall rule to block outbound traffic to the web server hosting the jnlp and jar files. After four seconds the splash screen went away and the software launched without any server log access entries or showing the downloading dialog. When I disabled that firewall rule, the server logs show access as the splash screen goes away within 2-4 seconds and the downloading dialog appears if necessary.

    This was with Windows 8 and the Windows Firewall rules. I didn't do any other testing, but I did before we started using this long ago. It is not a complaint we hear about from our customers so it seems to be working. I wonder why your experience is different. We don't set the update policy at all, it is whatever is default. I think when we started I tested with policy="prompt-update", but I can't be sure.

  • 1034092
    1034092 Member Posts: 17
    edited Jun 19, 2015 8:55AM

    This was not clear from my message, but actually I did two different tests, one without network connection and one with Tomcat down.

    I investiagted this further (with the JNLP shown at the bottom) and found the following behaviour:

    - Disconnect WLAN (Linux, Mac)/Disable network adapter (Windows 7 VM)

    I get a FailedDownloadException.

    - Blocking access to the download server with iptables on Linux host (Linux, Win 7 & 8.1 VMs)

    The application launches, but very slowly. I already see log output, but it still takes ages to launch. Maybe the Webstart classloader is blocking?

    - Windows 8.1 VM blocking access with a Windows Firewall rule (same as you did)

    This works like you described. I got a FailedDownloadException first, but couldn't reproduce it.

    - Tomcat down

    I didn't test this again, but I got an exception, too.

    What I would want that the application is always launched, no matter what prevented the download to succeed. But Webstart seems to react differently to various failures.

    So the only way to ensure it is always launches seems to be update="background", which has it's own problems as you mentioned above.

    My JNLP file:

    <jnlp spec="6.0+" href="myapp.jnlp" codebase="">
            <homepage href="" />
            <description kind="short">Description</description>
            <icon href="images/logo.gif" />
            <icon height="64" width="64" href="images/logo64x64.gif" />
            <icon height="32" width="32" href="images/logo32x32.gif" />
            <icon href="images/logo.gif" kind="splash" />
            <offline-allowed />
            <shortcut online="true">
                <desktop />
                <menu submenu="MyOrg" />
            <all-permissions />
        <update check="timeout" policy="always" />
            <property name="webstart.codebase" value="" />
            <property name="" value="true" />
            <j2se version="1.6+" />
            <jar href="lib/myapp.jar" version="3.0-beta-10" main="true" />
            <jar href="lib/jna.jar" version="3.4.0" />
            <jar href="lib/jersey-client.jar" version="2.6" />
            <jar href="lib/jackson-annotations.jar" version="2.2.3" />
            <jar href="lib/javax.inject.jar" version="1" />
        <application-desc main-class="org.myorg.MyApp" />
        <resources os="Windows" arch="x86">
            <nativelib href="lib/native-win32.jar" />
        <resources os="Windows" arch="amd64">
            <nativelib href="lib/native-win64.jar" />
        <resources os="Linux" arch="i386">
            <nativelib href="lib/native-linux32.jar" />
        <resources os="Linux" arch="amd64">
            <nativelib href="lib/native-linux64.jar" />
        <resources os="Mac OS X" arch="">
            <nativelib href="lib/native-mac.jar" />
This discussion has been closed.