 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2007WebStart caching test.
(quoting myself from an earlier thread*) > 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.409824.51170@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. > (quoting myself from an earlier thread*) > [quoted text clipped - 29 lines] > > Andrew T. 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. .. > >..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. > Thanks for the result. > [quoted text clipped - 13 lines] > > Andrew T. Yes, that was what happened to me. .. > > Did that happen even for the first picture? > > 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. >>> 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 >>>> My experience was the *first* download >>>> 1) showed a progress dialog (PD) [quoted text clipped - 10 lines] > > - Lew I used Firefox. What did you use? Is there any difference in performance on say *ux platforms form Windows? Andrew Thompson wrote: >>>>> My experience was the *first* download >>>>> 1) showed a progress dialog (PD) [quoted text clipped - 4 lines] >>>>> that failed for me. For this it was >>>>> 1) showed a PD saying 'verifying ..' Lew wrote: >> No anomalies for me. > 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 wrote: > >>>>> My experience was the *first* download [quoted text clipped - 8 lines] > >> No anomalies for me. > > 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. > FWIW - I was using IE on windows. I think it > is more related to the Java Plug-In for the OS. [quoted text clipped - 5 lines] > 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 > > 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. Lew wrote: >> 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'. 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 > Lew wrote: > >> I didn't use the plug-in. [quoted text clipped - 5 lines] > 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. > >>> My experience was the *first* download > >>> 1) showed a progress dialog (PD) [quoted text clipped - 4 lines] > > No anomalies for me. 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. > It was the 'second and every other' call > that failed for me. For this it was [quoted text clipped - 3 lines] > 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 On Feb 26, 1:40 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE- THIS.org> 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. > (quoting myself from an earlier thread*) > [quoted text clipped - 27 lines] > last October) the GG WITUN is not offering a > 'Reply' link for it (only 'Reply to Author'). 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.  SignatureDag. > >> 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. >>>> WebStart caching test - > .. [quoted text clipped - 10 lines] > > Andrew T. 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 > >>>> 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. >>>> WebStart caching test - > .. [quoted text clipped - 7 lines] > the first *success* off a Win based system, > What Java version are you running? 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> > >>>> WebStart caching test - .. > >> Loaded normally, .. > 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. ... > * Some results are still from machines with > unknown Java version. ... My "worked" result was with build 1.5.0_10-b03 Patricia > 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... On Feb 27, 2:30 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE- 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. > (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 On Mar 16, 6:54 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE- 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.