Watch the brief Introduction to Shared Shell Video to learn more about this useful collaborative service tool.
|
|
|
|
Shared Shell has become a commonly used tool throughout Sun Services. Feedback from Sun's customers, Services engineers and Partners has been great.
It had proven to be an easy to use, secure remote collaboration tool that really facilitates telephone-based service.
Shared Shell 4.2 was released to production in October. New features include:
The RAS (Reliability, Availability, Scalability) implementation is quite interesting. It uses Sun's Glassfish application server features, including Grizzly and Shoal, to allow support multiple servers to host Shared Shell clients. That lets us easily add more servers to support more sessions. And, if a server fails, the clients get reconnected to their sessions quickly.
I'll leave it to our outstanding Shared Shell engineers to describe how this all works.
Meanwhile, be sure to check out Shared Shell at http://sun.com/123.
And, we're working on the next release, adding features to make Shared Shell even easier to use.
|
|
|
|
One of the comments on Joerg Moellencamp's recent blog entry talked about Gnu "screen" providing similar functionality with Shared Shell (my apologies if I'm not getting the gist of the German thread on that entry). I thought I'd make a few comments about the difference between Gnu screen and Shared Shell at the user- and technical level. I don't consider myself an expert on screen, so please make any corrections down in the comments section.
Here are some of the obvious difference I can see:
In summary, I don't want to say one is better than the other -- I think they serve orthogonal use cases: screen can work well in a LAN or WAN environment, especially where every participant has a login on a gateway host or on the target server itself. It's fast and light and good at what it does -- multiplexing 1 or more terminal sessions.
Shared Shell, on the other hand, was designed from the betting as a remote support tool, where the initiator and participants are separated by the Internet, and tries to help with the end-to-end connectivity. It's also designed to be run by less-experienced administrators and started from a pure-GUI environment like Windows. There's also nothing stopping you from running screen inside a Shared Shell session if you need to connect to multiple systems, have multiple tasks going at the same time, or handle the possibility of an unexpected disconnect. I believe our vt100 emulation is sufficient to use all of screen's capabilities.
As always, feedback and comments are appreciated.
|
|
|
|
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.
|
|
|
|
History of Shared Shell from its research roots to the 4.0 version available today.[Read More]
|
|
|
|
gnu-screen shared shared-shell shell
This theme brought to you by the Sun Green Team.
Go Green!