Ok, one really good reply which I have forwarded below along with my original question at the end of his reply. Thanks, Tim Chipman. Got another reply suggesting a hardware upgrade. Bottom line to solve the interface glitch was to try different versions of jre until it was resolved. This has also affected performance in the past. The PCs were running j2se1.4.1_02. I had j2se1.4.1_04 with the glitch. I tried downloading and running j2se1.4.1_02, but that didn't fix it. Finally got it with j2se1.4.2_03. All the interface glitches went away, and there may have been a slight performance improvement. I recall that the 1.3.1 was noticeably more sluggish on a previous release of the vendor's java app. For performance, it appears that an OS upgrade to 9 might help, but I would have to coordinate that with a compatibility check with the SunRay Server Software that I'm running. Probably need to upgrade it as well, if it would work with Solaris 9 at all. Clearly, a hardware upgrade would give a performance boost, but that would cost real money. Not likely. Thanks, --------------- Chris Hoogendyk - O__ ---- Network Specialist & Unix Systems Administrator c/ /'_ --- Library Information Systems & Technology Services (*) \(*) -- W.E.B. Du Bois Library ~~~~~~~~~~ - University of Massachusetts, Amherst <choogend@library.umass.edu> --------------- -------- Original Message -------- Subject: Re: java application from PC to Solaris 8 Date: Tue, 08 Jun 2004 11:23:20 -0400 From: Tim Chipman <chipman@ecopiabio.com> Organization: Ecopia BioSciences To: Chris Hoogendyk <choogend@library.umass.edu> References: <40C5C80F.2010607@library.umass.edu> Hi, just a few things I can suggest, maybe of use (?) -from what I can tell, many of these JAR file wrappers extract the JAR somewhere onto your PC running the .exe-wrapped java app. Thus, if you can find it .. bingo, you have a generic JAR you can run natively on unix (for example). Thus, I might suggest firing up the app on a windoze box, looking in the obvious places, see what you find -- while the app is running. (ie, c:\windows\temp, c:\temp, ... etc ...) - might even be worth doing a (drive | system) wide search for *.jar and seeing what you get. -that detail aside, -from what I understand, some java apps are supposed to run "much" faster on solaris9 than they used to run on solaris8 and prior. It might be worth doing a test install on a generic testbox just to see if you observe any performance difference with your app on the different operating environment. Solaris10 (in beta but functional right now IIRC) is meant to give further improvements, which MIGHT be an option / of interest. AFAIK the performance benefits typically related to threading ... so a GUI-user app may not get much boost ... but I suppose the only way to be certain is to do a bit of testing. -finally: we're using sunray environment here also, and we ended up doing some "evil sneaky tricks" to get better performance for user apps. Initial issues centred simply around the basic problem, a sunray server needs a fair bit of resources to "drive" 20 concurrent sunray sessions, especially if the users are not just doing "trivial work" (ie, people running web browsers, word processors, etc - with lots of screen update content :-). IMHO sun's scaling recommendations WRT sunray servers .. are somewhat dated / misleading... ie, we found that an e250 (2x400mhz / 2 gigs ram) was barely able to run 15-20 concurrent sessions, IF all those people were running netscape 4.7X locally on the sunray server as well. ('barely able to run' meaning, screen refreshes became unacceptable in my opinion, although "things did work" in a manner of speaking). Also note that if you need a newer web browser (such as mozilla / netscape 6.0 or later) -- then the situation gets urgent much faster, due to heavier CPU/Memory footprint of the app. When we offloaded the netscape to a different box, and piped via x-forwarding the app back to the sunray server -- the e250 had MUCH better performance, able to handle 25 concurrent sessions without any screen refresh issues. (initially we did this using a nearby e450 that was under-utilized as an "app server" for Netscape 4.7 ...) We ended up migrating to an e450 (4x400mhz/2gigs ram) for our sunray server though, to give us capacity for ~50 concurrent users, and better performance in general ... as I was able to pick up a refurb e450 for a steal from a reseller (this is not at all difficult to do these days... ) Second big "sneaky evil trick" (the really evil thing :-) - was to deploy a dual-athlon app server running linux, which is where we run Mozilla, OpenOffice, and other misc user apps. We're using centralized kerberos for user authentication, and homedirs are all NFS mounted anyhow, so with the magic of small wrapper scripts on the sunray server, users run these apps without ever realizing they are benefiting from the CPU performance of 2000mhz athlons, which are **much** snappier than 400mhz Ultrasparc .. and of course, a dual-2000mhz athlon app server only costs $2000 approx, ie, it is virtually free compared to the sunray server it is offloading. We've had this arrangement for ~1.5 years now and it works amazingly well - end users get more current apps, better performance, and the sunray server is far!!! happier not having to run these CPU-hungry apps. So: You might need to consider something like this, as one possible route to getting improved performance for your java app. Oh yes: We use java here quite a lot too for some standalone and web-based apps ... for sure, you may need to standardize the JVM version or do extensive testing of versions and impact on software behaviour. We've observed certain bugs that only surface for a specific app in a particular version of the JVM, which ultimately has forced us to use very specific config of (App:JVM:client platform) ... to ensure that things work well for our end users. I realize this is frustrating but it is alas the state of Java, it seems. (ie, code once, debug everywhere ....) Hope this is of some use. Please feel free to query back if anything needs clarification. --Tim Chris Hoogendyk wrote: > <Intro> I have a vendor java application (Millennium Circulation > Client from Innovative Interfaces Inc's Integrated Library System -- > Innopac) that was primarily developed for use on Windows PCs with JRE > 1.4.1_02. I have gotten their previous versions to run on Solaris 8 > for SunRay Thin Clients through a bit of finagling (see > http://www.library.umass.edu/systems/iug/2003/technote9.html). Anyway, > this time, they packaged it differently, and the PC version was > launching from a binary .exe file, so I couldn't get it running by > moving it over from the PC. However, once we got the III Server > upgraded, and the older client failed, I was able to change the script > to launch the older client from the newer JRE. When I did that, the > server connected and downloaded updated Java code for the jardir. So ... > now I have two questions. </intro> > > I'm getting a cursor focus issue that does not happen on PCs. If the > cursor is in a data entry field, we scan a book with a bar code > scanner, it goes into the field, an alert comes up, we respond to the > alert, the cursor does not go back to the data entry field. So, they > have to go to the mouse, click in the field, and then scan the next > book. May not seem like a big deal, but with a stack of 50 books, or a > cart of 200, it becomes a big deal. On a PC it goes right back to the > data entry, so they can scan, scan, scan . . . without interruption. > Could this be an issue with particular versions of JRE? It happens > that I have 1.4.1_04 and the PCs have 1.4.1_02. > > Second, it's a bit slow. I have an E450 with 20 SunRays. I'm wondering > if there are any obvious ways of tuning and speeding java up (I can't > diddle with their code). Of course we are comparing against PCs that > are 1.4 to 2.2 GHz with Windows 2000. Would things completely break > and/or slow down if I installed and used 64 bit Java? Or would that > speed up? > > TIA > > > > > --------------- > > Chris Hoogendyk > > - > O__ ---- Network Specialist & Unix Systems Administrator > c/ /'_ --- Library Information Systems & Technology Services > (*) \(*) -- W.E.B. Du Bois Library > ~~~~~~~~~~ - University of Massachusetts, Amherst > > <choogend@library.umass.edu> > > --------------- > _______________________________________________ > sunmanagers mailing list > sunmanagers@sunmanagers.org > http://www.sunmanagers.org/mailman/listinfo/sunmanagers _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Jun 8 13:06:32 2004
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:31 EST