WebStart caching test.
Andrew Thompson
> WebStart caching test - a test of the 'lazy' download
> attribute (good for getting applications on-screen fast,
> amongst other things).
<http://www.physci.org/jws/cache/#eg6>
> The theory is that the (<20KB) of classes of this
> (sandboxed) application should spring onto screen
> quickly, but once the user clicks a list entry, the
> media files (ranging from 270-370Kb) will then be
> downloaded and cached (and displayed).
The aim of this test is to get a workable progress
dialog, for the lazy downloads.
This is now version 6, and I am still getting
odd results. It seems to work just fine off the
local file-system, but fails when coming off the
net (see the link for details).
Can anyone confirm the same behaviour (fails
for net, works off file system)?
* Note. This was intended as a follow-up to msgID
1160324024....@h48g2000cwc.googlegroups.com
with the same Subject. For some reason (perhaps
because the last post on that thread was
last October) the GG WITUN is not offering a
'Reply' link for it (only 'Reply to Author').
Andrew T.
John T
progress bar worked but when the pictures displayed in the frame, the
dialogue was still on my screen.
Andrew Thompson
> Andrew Thompson wrote:
..
> >..It seems to work just fine off the
> > local file-system, but fails when coming off the
> > net (see the link for details).
>
> > Can anyone confirm the same behaviour (fails
> > for net, works off file system)?
> Hi Andrew, I clicked on your link and went to the jnlp link. The dl
> progress bar worked but when the pictures displayed in the frame, the
> dialogue was still on my screen.
Thanks for the result.
Did that happen even for the first picture?
My experience was the *first* download
1) showed a progress dialog (PD)
2) the dialog showed progress
3) when the resource arrived, the dialog vanished
It was the 'second and every other' call
that failed for me. For this it was
1) showed a PD saying 'verifying ..'
2) no progress was shown, and the dialog ..
3) did not disappear after the picture
arrived (though it could be closed by
user).
Andrew T.
John T
> Thanks for the result.
>
> Did that happen even for the first picture?
> My experience was the *first* download
> 1) showed a progress dialog (PD)
> 2) the dialog showed progress
> 3) when the resource arrived, the dialog vanished
>
> It was the 'second and every other' call
> that failed for me. For this it was
> 1) showed a PD saying 'verifying ..'
> 2) no progress was shown, and the dialog ..
> 3) did not disappear after the picture
> arrived (though it could be closed by
> user).
>
> Andrew T.
>
Andrew Thompson
> > My experience was the *first* download
> > 1) showed a progress dialog (PD)
> > It was the 'second and every other' call
> > that failed for me. For this it was
> > 1) showed a PD saying 'verifying ..'
> Yes, that was what happened to me.
Thanks for clarifying. :-(
Andrew T.
Lew
>>> My experience was the *first* download
>>> 1) showed a progress dialog (PD)
> ...
>>> It was the 'second and every other' call
>>> that failed for me. For this it was
>>> 1) showed a PD saying 'verifying ..'
No anomalies for me.
That Kev is talented.
- Lew
John T
performance on say *ux platforms form Windows?
Lew
>>>>> My experience was the *first* download
>>>>> 1) showed a progress dialog (PD)
>>>
>>> ...
>>>
>>>>> It was the 'second and every other' call
>>>>> that failed for me. For this it was
>>>>> 1) showed a PD saying 'verifying ..'
Lew wrote:
>> No anomalies for me.
John T wrote:
> I used Firefox. What did you use? Is there any difference in
> performance on say *ux platforms form Windows?
I used Firefox under Fedora Core 6, running the Java under j5.
- Lew
Andrew Thompson
Thanks.. What OS/Java are you running?
> That Kev is talented.
Would you believe that
a) He claims to have lost his ability to
focus.
b) That was simply a doodle intended to
show his daughter some techniques for
color mixing. He never expected it to
be publicly seen.
(Some of the works he did in his younger
days were *awesome*, but unfortunately I
have only been able to get poor quality
reproductions of them)
Andrew T.
Andrew Thompson
> Andrew Thompson wrote:
> >>>>> My experience was the *first* download
> >>>>> 1) showed a progress dialog (PD)
>
> >>> ...
>
> >>>>> It was the 'second and every other' call
> >>>>> that failed for me. For this it was
> >>>>> 1) showed a PD saying 'verifying ..'
> Lew wrote:
> >> No anomalies for me.
> John T wrote:
> > I used Firefox. What did you use?
I do not believe the browser should be relevant.
(Though - famous last words, a recent problem
with a memory leak in a JWS app. was revealed
to be related to the browser* that launched it,
combined with Java Control Panel settings that
advised 'use browser as proxy' or something
like that)
* OK - the 'OS component' (IE).
>...Is there any difference in
> performance on say *ux platforms form Windows?
> > Is there any difference in
> > performance on say *ux platforms form Windows?
>
> I used Firefox under Fedora Core 6, running the Java under j5.
FWIW - I was using IE on windows. I think it
is more related to the Java Plug-In for the OS.
So far we have two failures for Windows,
using both FF and IE, and one success using
FF in Linux.
I am beginning to see a pattern, which suggests
the Windows Java Plug-In is the problem.
Andrew T.
Dag Sunde
Firefox 2.0.0.1, WinXP SP2
Loaded normally, Showed progress for each picture the first time
i clicked on each. Progress dialog disappeared properly after each.
Second time around, cache obviously worked; No progress dialog,
and the picures appeared instantaneously.
Third time I opened it from IE6, and it behaved like the second time.
(Already in cache).
Last time Opened from Opera 9: Same result, all ok.
--
Dag.
Lew
>
> FWIW - I was using IE on windows. I think it
> is more related to the Java Plug-In for the OS.
>
> So far we have two failures for Windows,
> using both FF and IE, and one success using
> FF in Linux.
>
> I am beginning to see a pattern, which suggests
> the Windows Java Plug-In is the problem.
I didn't use the plug-in.
- Lew
Chris Uppal
> It was the 'second and every other' call
> that failed for me. For this it was
> 1) showed a PD saying 'verifying ..'
> 2) no progress was shown, and the dialog ..
> 3) did not disappear after the picture
> arrived (though it could be closed by
> user).
That's what I see too. WinXP, 1.6 JRE, FireFox 1.5.
Revisiting the JNLP works OK, though -- the cache is used without any drama.
-- chris
Andrew Thompson
> Andrew Thompson wrote:
>
> >> WebStart caching test -
..
> Firefox 2.0.0.1, WinXP SP2
>
> Loaded normally, Showed progress for each picture the first time
> i clicked on each. Progress dialog disappeared properly after each.
> Last time Opened from Opera 9: Same result, all ok.
Huh! Your result is anomalous in being
the first *success* off a Win based system,
What Java version are you running?
Andrew T.
Andrew Thompson
THIS.org> wrote:
> Andrew Thompson wrote:
> > It was the 'second and every other' call
> > that failed for me.
> That's what I see too. WinXP, 1.6 JRE, FireFox 1.5.
Thanks chris. That's 3 out of 4 failures
(all worked OK for Dag) for Win. based
machines so far.
> Revisiting the JNLP works OK, though -- the cache is used without any drama.
(phew) ..at least part of it seems to
work reliably!
Andrew T.
Andrew Thompson
> Andrew Thompson wrote:
>
> > FWIW - I was using IE on windows. I think it
> > is more related to the Java Plug-In for the OS.
> I didn't use the plug-in.
Is this a naming problem? I have gotten to
referring to any old Java on a computer as a
'Java Plug-In'. Perhaps I should just revert
to saying 'Java'.
Andrew T.
Patricia Shanahan
I didn't realize success was so unusual. WinXP SP2, Firefox 1.5.0.10.
The only anomaly was some hesitation and rewinding of the progress bar
during download of the third image, but that may be due to using an
802.11 wireless link.
Patricia
Andrew Thompson
> Andrew Thompson wrote:
> >>>> WebStart caching test -
...
> I didn't realize success was so unusual.
I have had good results from most of the
web start API examples, from the first test.
I have had success with lazy downloads
*without* a progress dialog (which makes
for a horrid user experience). It is just
this example of both using lazy downloads
combined with a progress dialog, that is
causing a problem.
Note that if these resources are marked
'eager', it is very easy for the developer,
and the end user gets a (working) progress
dialog as a matter of course.
>..WinXP SP2, Firefox 1.5.0.10.
>
> The only anomaly was some hesitation and rewinding of the progress bar
> during download of the third image, but that may be due to using an
> 802.11 wireless link.
OK. I am counting that as a second success
for Java on Win., I also have observed (a
form of) the 'rewinding' effect you mention.
The progress dialog bar did not actually go
backwards, but it sometimes pauses for 'a few
moments' and the time changes to a message
along the lines of 'download stalled', also
sometimes as the seconds are counting down,
they will 'jump back up' (19 sec., 18 sec.
... 23 sec. 22 sec.).
I am guessing the 'download stalled' message
appears if the stream delivers 0 bytes for a
few seconds, and the second is the result of
the stream byte rate dropping.
I need to summarise these results in a
table, I can see no clear pattern now,
with the few Win. successes thrown into
the mix.
Andrew T.
Dag Sunde
From plugin console:
<quote>
Java Plug-in 1.5.0_10
Using JRE version 1.5.0_10 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings
</quote>
Lew
>> I didn't use the plug-in.
Andrew Thompson wrote:
> Is this a naming problem? I have gotten to
> referring to any old Java on a computer as a
> 'Java Plug-In'. Perhaps I should just revert
> to saying 'Java'.
I suppose so. Sun says "Java Plug-in" to refer to the component that runs
applets in browsers. I use a download association that tells Firefox to
forward .jnlp files to an instance of a v5 WebStart. This is the same type of
association that tells Firefox to forward .pdf files to a PDF viewer.
- Lew
Andrew Thompson
> Lew wrote:
> >> I didn't use the plug-in.
> Andrew Thompson wrote:
> > Is this a naming problem? I have gotten to
> > referring to any old Java on a computer as a
> > 'Java Plug-In'. Perhaps I should just revert
> > to saying 'Java'.
>
> I suppose so. Sun says "Java Plug-in" to refer to the component that runs
> applets in browsers.
Yeah (groans) with the way Sun changes their
minds about nomenclature from release to release,
I have come to view their terms as malleable,
and probably am using them quite randomly now.
>I use a download association that tells Firefox to
> forward .jnlp files to an instance of a v5 WebStart. This is the same type of
> association that tells Firefox to forward .pdf files to a PDF viewer.
Thanks for clarifying.
Andrew T.
Andrew Thompson
> Andrew Thompson wrote:
> > On Feb 25, 9:13 pm, "Dag Sunde" <m...@dagsunde.com> wrote:
> >> Andrew Thompson wrote:
>
> >>>> WebStart caching test -
..
..
> Java Plug-in 1.5.0_10
> Using JRE version 1.5.0_10 Java HotSpot(TM) Client VM
Interesting. As I was preparing the table of
results, I noted the two failures* were using
Java 1.6, and the ones that worked*, were
using 1.5.
* Some results are still from machines with
unknown Java version.
I will set up alternate versions of the launch
file, that lock the test in to either 1.5, or 1.6.
Andrew T.
Patricia Shanahan
...
> * Some results are still from machines with
> unknown Java version.
My "worked" result was with build 1.5.0_10-b03
Patricia
Chris Uppal
> Interesting. As I was preparing the table of
> results, I noted the two failures* were using
> Java 1.6, and the ones that worked*, were
> using 1.5.
That seems to be it.
Using original JNLP URL:
http://www.physci.org/jws/cache/6/jwscache.jnlp
Then
<path to jre1.5>\javaws <url>
works fine. But:
<path to jre1.6>\javaws <url>
shows the same misbehaviour.
Unfortunately, opening:
http://www.physci.org/jws/cache/6/jwscache5.jnlp
from my browser still doesn't work properly. First it prompts me to check that
it's OK to use an older JRE -- I said OK (I wouldn't normally). But the
problem still persists. I think it's a problem in javaws.exe itself since the
problem doesn't go away even though it is (one hopes) loading the JVM from the
1.5 installation. A bit of experimentation suggests that the 1.6 javaws.exe
uses deploy.jar from the 1.6 jre, even if the JNLP file asks for a 1.5 JVM.
Incidentally, javaws also uses the 1.6 cache directory even when running a 1.5
jre. If you execute:
<path to jre1.5>\javaws -viewer
then you can see that there's nothing in the 1.5 cache. But running the
<path to jre1.6>\javaws -viewer
shows the cached application.
-- chris
P.S. Just got a midly amusing message from 1.5 javaws:
Warning:
You have exceed the recommended amount of disk space for JNLP
Applications and Resources in your cache.
You are currently using 3959bytes
The recommended limit is: 167bytes
...
;-)
It seems that 1.5 and 1.6 store the cache settings in the same place, 1.5 must
disagree about the units. If 1.6 is configured for a maximum of 167 MB, then
1.5 interprets that as bytes. But if you set 1.5 to 1 MB, then 1.6 interprets
it as 1GB.
Another winner from Sun...
Andrew Thompson
THIS.org> wrote:
Re. examples in
<http://www.physci.org/jws/cache/6>
..
> Unfortunately, opening:
> http://www.physci.org/jws/cache/6/jwscache5.jnlp
> from my browser still doesn't work properly. First it prompts me to check that
> it's OK to use an older JRE -- I said OK (I wouldn't normally). But the
> problem still persists.
(JWS prompts for download of installed JRE)..
See if the instructions here, help get
that JRE version available*.
<http://www.physci.org/jws/version.html#enable>
* If you would be so kind [and with the
sheer hide to ask, some (checks watch) 17
days after this thread ground to a halt
due to my being busy on other matters].
Andrew T.
Chris Uppal
> (JWS prompts for download of installed JRE)..
>
> See if the instructions here, help get
> that JRE version available*.
> <http://www.physci.org/jws/version.html#enable>
I'm not sure what you want me to test ?
The explanations at your link (above) are good, but my webstart installation
was already configured to "activate" one installation each of 14.2, 1.5.0, and
1.6.0. So there's nothing (that I can see) that I should be changing or
fixing.
That part of it seems to work OK -- I get a prompt asking if I'll permit your
application to run on an earlier JVM than my current installation. But apart
from that (which I assume is the design behaviour) there don't seem to be any
problems relating to selecting a JVM. (It no longer tries to download and
install a 1.5 JVM, as it did in one of your earlier tests.) The only problem
is the inappropriate security dialog where a download progress dialog should
be.
I'm reasonably sure (not /dead/ certain) that following the:
http://www.physci.org/jws/cache/6/jwscache5.jnlp
link causes the browser/OS to invoke the 1.6 WebStart launcher, which reads the
JNLP file, and therefore loads the 1.5 JVM, but that it actually uses the
deploy.jar from the 1.6 implementation of WebStart. And that's why it shows
the same problem as would happen if the JNLP file didn't ask for a specific
JVM.
But if there's something else you'd like me to check, then I'll give it a
whirl...
-- chris
Andrew Thompson
THIS.org> wrote:
..
> ..So there's nothing (that I can see) that I should be changing or
> fixing.
..
> ..(It no longer tries to download and
> install a 1.5 JVM, as it did in one of your earlier tests.)
OK - thanks. That was the vague impression I
had got (perhaps left over from an even earlier
thread) so intended to throw together a page to
cover that aspect of getting earlier versions
before proceeding. (I have already linked to
it on the Sun forums as well, in reply to a
question.)
I will review your other replies, do some more
tests locally, and decide where to go from here.
Andrew T.