Forcing Webstart To Redownload

Networking & Multiplayer
#1

Stupid F*(&ing webstart and its stupid f"(*ing caching is driving me nuts. :frowning:

I always seem to get this snag, and havn’t figured out a way of avoiding it yet - when I’m putting an app up as a webstart app for the first time webstart caches far too much, far too often. In particular it caches the jnlp “somewhere” and refuses to go fetch a later one (despite the original jnlp referencing its own location, and despite me running the updated version either locally or from the web).

In this case I forgot a tag, which has since been replaced. Even removing the app via the webstart GUI doesn’t work - it clears the jar cache, but when relaunching it doesn’t download the new jar. The error dialog clearly shows it using the old jnlp too.

The only way around this I’ve found is:

  • Manually trying to find the cached jnlp on the HD (tricky, and it seems to have multiple copies)
  • Constantly re-launching the app until webstart decides to re-get the jnlp (rare)
  • Waiting X hours in an attempt to make the above more likely

Gah! Anyone any hints or ways around this?

#2

The offline allowed tag is to blame. If its omitted jws will always look for an up to date version.

Just dont allow offline mode during beta testing :wink:

edit: Eh… maybe your browser is to blame? Clear its cache.

#3

  1. Don’t use the timestamp versioning system, use the other one (whose name I’ve forgotten, but which needs you to run a small servlet, perl CGI, or similar on the server - sun provides a reference impl in servlet form for free)

  2. check, double-check, triple-check everything to do with the URL where you’re fetching the jnlp from. This includes:

  • is jws being crap and thinking two URL’s are identical when they blatently are not? (or vice versa)
  • if the newer version has one of a certain class of errors in it, jws silently ignores it (YAY!)
  • is the timestamp on the server correct? (because Sun’s timestamp checking code IME is a long way from perfect)
  • is the server handling HEAD requests correctly?
  • …is the request even getting as far as the server? (I’ve had problems with those evil evil evil “transparent ISP webcaches” before - everyone from AT&T to Verizon getting their fat greedy paws in the way and intercepting AND CORRUPTING my website traffic. The extent to which I hate every single person who misconfigured their ISP’s webcache and screwed me + their customers cannot be described in mere words. And it still happens today :()

Although it sounds like the nuclear option, a packet-sniffer is your friend. It’s the only way to find out what’s really going on, what with the unacceptably awful error handling in webstart at the moment.

#4

I suspect the allow-offline tag is indeed to blame. As far as I can tell it’s not even requesting anything over the internet, just launching the thing from the cached files. Likewise I don’t expect the server or ISP to be the problem, as I’ve had the same snag with 3 different servers and 2 different ISPs.

I’ve found that deleting the 3 (!) cached copies of the jnlp doesn’t work, but deleting them and the main jar will trigger a re-download. Or at least, it seems to have worked this time…

#5

This is why I said you need a packet sniffer: find out EXACTLY what jws is sending out, what it is receivnig, and then deduce what it’s trying to do.

#6

You might find the problem is at the server end…

Cas :slight_smile:

#7

http://www.ethereal.com/

Helped me countless times :slight_smile: