Version 4.0.1 released last night
Thursday Apr 12, 2007
We released version 4.0.1 of the Shared Shell client and server last night. When you try and start it the next time, Java Web Start will automatically upgrade you to this new version. It's a bug-fix release that improves stability & responsiveness under load.
One of the bug-fix-as-feature items that made it into this release was to get the Chat window to be unicode-clean, passing through all characters -- even CJK (Chinese/Japanese/Korean), cyrillic, and others:
It works even in a western X11 environment (left) thanks to Java's composite fonts, as well as on an all-Unicode platform like Mac OS X (right) or Windows XP. Previously, the chat window was limited to western characters (ISO-8859-1, specifically). The terminal window itself is still limited to western and VT100 characters due to font and terminal emulation/environment limitations. You can use our Feedback link to let us know if this is or is not an issue for you.
The performance and responsiveness fix was a more interesting one, due to some of the internal queueing and buffering inside Shared Shell's message handling code. Basically, if you had a command that had a large & constant rate of output (say, running "ps -ef" on one of our internal SunRay servers in a loop, outputting 100+Kb at a shot), output to the Shared Shell terminal window would start to buffer significantly and, if continued indefinitely, would thrown an OutOfMemoryException. In the 4.0.1 release, we do some rate-limiting to ensure the UI stays responsive and memory-limited. It also means that Ctrl-C will work in the case of overwhelming output, after a few seconds. I'll see about going into some details on that problem in my personal blog since it's more of interest for a developer than a Shared Shell user.
A final item that was pushed out in this release is setting a relatively small start- and maximum heap size for Java in our Java Web Start .jnlp file. We now set a maximum of 24Mb, though in most cases Shared Shell consumes between 8-11Mb of heap size (a little bigger than that for "RES" state if you watch it in a program like top). While Java chooses a reasonable heap size on a desktop-class machine or PC, it tends to make very poor memory size defaults when running a desktop application like Shared Shell on a really big server. The Java team refers to this as GC ergonomics, so the JVM will take up to 1/4 of the machine's physical memory size as its maximum heap size. Those default ergonomics are a really bad idea in a SunRay environment, where you have a large machine, like a 16-way machine with 64Gb of RAM, but has 30 users on it with Gnome & desktop applications and a load average of 16! Anyway, Shared Shell will play better in this kind of environment now.
Give it a try and let us know what you think.
|
|
|
|
