[Webteam] Notes on Altitude in box3
Chris Cunnington
smalltalktelevision at gmail.com
Wed Nov 14 13:36:56 UTC 2012
I deployed Altitude in box3 on Thursday. It's Wednesday so that's almost
a week.
There's good news and bad news on that front.
The look of the site itself is not an important consideration in this
discussion, I don't think. It has the content of squeak.org, which is
links. Changing it to what it needs to look like is trivial. The problem
with the design of the site is agreeing on what people want, which is a
pain, because people don't know what they want, they just know they
don't like what they're looking at. So, the initial impression of the
sight I'm not about to trouble myself over too much, until people have
some idea of what a "Squeak homepage" is supposed to look at.
The good news about Altitude is, in my opinion, that it is the fastest
web framework every to be deployed in a Smalltalk image. The bad news is
that at the moment it isn't 100% stable. I've killed and restarted the
process twice.
If you try the site at http://173.246.101.237:8624 you'll see it moves
at the rate of a laser beam. Go to Smalltalk Hub and compare.
http://smalltalkhub.com/ Or
http://www.esug.org/wiki/pier/Conferences/2012 (Wait for how long it
takes for the browser to stop spinning.) So, Altitude is dead fast.
It has a problem though. On Monday I checked the site and Chrome said it
could not be reached. I hit the ip and port. Nope. I logged in and top
-d 1 to see it is now consuming 99% of CPU. Not good. I killed the
process. I just did it again this morning the day after. There is no
debug log printed into the image directory. So there is nothing to check.
Now, I think I can tell you how to reproduce the problem in localhost
reliably. Build a site with Altitude. Make an intentional mistake.
Say you want a break tag in your page. You type in html b, when what you
should have typed is html br. The basic checker will not see a syntax
error, because there is an existing b tag in the canvas. But really,
it's gibberish. Go to your browser and press refresh to see what you've
changed. You get an error. Here's the important part.
The browser is still spinning. If you touch the debugger window while
it's still spinning, then your image will hang, It'll start consuming
99% of CPU. You'll have to break out the Activity Monitor and kill.
Guess what? You're work is now lost. Do that three times in a row and
your mood will start to change. As a preventative measure, I started
saving the image every time I was about to refresh the browser.
But here's the thing. If you stop the browser spinning, stop it from
requesting the server, then you can use the debugger window without
incident. I think this is related to the problem I see in box3. And I
think it has something to do with Altitude/Xtreams not knowing when to
stop.
Kom, however weird, is very stable. WebClient, more pleasant, is after
two years seen as a stable server. It's the reliability of the server
that matters, not the application, so much. And what happens when you
type a wrong tag into GreenNeon, HTTPView2, or Seaside?
First of all it doesn't crash. Second, it prints a walkback in the
browser, which is very useful. (I take it that the server gets output
from Exception description and routes it to the browser.)
WebClient assumes a difference between server and application. I think
that perhaps Altitude has see more effort spent in creating the
application than ensuring the server is as reliable as it needs to be.
Or giving a developer the kind of feedback expected in seeing a walkback
in the browser. But, my God, it is so fast. The fastest.
I am certain of two things. The first is that we cannot watch to reboot
squeak.org each day. The second is that I have every confidence that
with a little work Altitude can be hardened so that it doesn't crash.
This is, after all, the first time Altitude has every been deployed in a
server. I think having the fastest framework is worth the effort.
Chris
More information about the Webteam
mailing list