You are currently browsing the monthly archive for February 2008.
It’s an absolutely beautiful day today. Every February we get a week of sunny, fifty degree weather and it looks like this is the week. It is so nice to see the sun! Over the holiday weekend we were able to take our dogs for a run in a nearby dog park. It’s a real treat to see a Saluki in full flight.
Besides playing with dogs, I’ve spent some time playing with and cleaning up some things in GLASS. I’ve published a new version of the GLASS package (GLASS-dkh.88) and here are some of the hightlights:
- I’m getting happier with the remote debugging factility – the steps for debugging are greatly simplified and I’ve even replaced the Hyper button on the GemStone Transcript with a Debug button that will open a debugger on the first continuation in the RcQueue (you’ll need to load GemStone-dkh.240 into your Squeak image for this feature). When you’re in production (#deploymentMode == true), the debug continuations are unconditionally added to the queue.
- In the same vein as remote debugging, I’ve added a consolidated object log where you can dump a LogEntry into an RcQueue from any one of the gems serving Seaside requests and view the logged objects in the comfort of your own development image. No need to muck around in N different logs to look for stack traces or important error messages.
- You may have noticed that in the past I have been somewhat vague whenever the subject of commit failures was brought up. Now, when you hit a commit failure, we drop a transactionConflicts Dictionary into the object log (see the comment in System class transactionConflicts for a description of its contents), and simply retry the HTTP request. If retry fails 10 times in a row, we throw in internal error.
I’ll be writing a couple of posts in the next week or so to provide more details.
If you’ve read the section on Hyper in the Terse Guide to the GLASS Tools, then you realize that you have to go through a hoop or two to debug your Seaside application in GLASS. With 3 gems serving Seaside pages in the appliance, any one of the gems can get a walkback while processing a request.
Until today, we didn’t have a good story for remote debugging.
Last night, I was mulling over the different approaches that we could take for doing remote debugging. As I thought about it, I realized that when the ‘Debug’ link is pressed in a Seaside, it wouldn’t be hard to snap off a continuation and stash it in a persistent collection and then in a development vm (one with Squeak attached), the continuation can be activated in a debugger.
Persistent continuations are used throughout GLASS, so it isn’t a big stretch to use them for remote debugging.
I spent a couple of hours this afternoon on an initial implementation. The end result at this point is somewhat crude, but functional.
If you want to give the remote debugger a try, just load up the package GLASS-dkh.83.mcz. Then head over to http://glass/seaside/tests/alltests in your browser:
- Click on the Error tab
- Click on the ‘Raise zero divide’ link
- Click on the ‘Remote Debug’ link on the walkback page.
- Follow the instructions on the page for bringing up the debugger in your development image.
You can save code in the debugger, set breakpoints and step around. There are a couple of problems with proceed, so unless you’ve set a breakpoint that prevents flying off the end of the stack, you shouldn’t use proceed. By implication there are certain points in a stack that you can’t step over. Don’t press the ‘Halt Execution’ link, because the halt is not caught by the remote debugger. These problems and a cleaner interface will be taken care of as we move forward.[Updated 4/10/2009: Halts have been safely caught for about a year now:)].
Finally, the remote debugging code won’t interfere with the the interactive debugging as described in the Terse Guide to the GLASS Tools.
James Robertson has posted the audio for James Foster’s talk on GLASS at the Ottawa Carleton Smalltalk Users Group last week.
David Buck recorded the audio.
If you went to Winterlude instead of attending James’ talk, you’ve got another chance to hear him talk about Seaside.
Many thanks to David Buck, James Robertson and Cincom.
Head on over to the STIC site and register for Smalltalk Solutions 2008.
jcrawler is a good tool for load testing Seaside applications – in theory. Unfortunately, it takes a little bit of work to modify jcrawler to get it to the point where it can be used to load test Seaside applications. So here’s my story…
The Story
In the last week I’ve started putting together some examples of persistence for GLASS (I’ll write a post about them when I’m happy with the examples). As I have mentioned before, you need to use different techniques to manage concurrency in GemStone/S, because you will be using multiple vms to serve web pages and Semaphores can’t be used. The examples illustrate several of the techniques that you can use to avoid transaction conflicts. As part of the exercise, I needed to find a way to test for transaction conflicts.
In order to create a transaction conflict, you need to have two web requests hit your web server at exactly the same time. I’ve used siege in the past for load testing, but siege uses constant URLs, not too useful for banging arbitrary URLs buried in the depths of your Seaside application.
To effectively beat on a Seaside application (especially if you want to expose concurrency bugs) you need a load tester that will crawl through your site, pick up the dynamically generated URLs and feed them back into the mix.
I knew that WAPT had been used by several folks for Seaside Load Tests, but I didn’t see site crawling mentioned in the feature list for WAPT. Beside that I’m doing my work on Linux boxes, so a Windows-only tool would not be convenient.
Without trying too hard, I found a site that listed a ton of Web Test Tools and up near the top of the of the Load and Performance Test Tools section there was a listing for jcrawler:
An open-source stress-testing tool for web apps; includes crawling/exploratory features. User can give JCrawler a set of starting URLs and it will begin crawling from that point onwards, going through any URLs it can find on its way and generating load on the web application. Load parameters (hits/sec) are configurable via central XML file; fires up as many threads as needed to keep load constant; includes self-testing unit tests. Handles http redirects and cookies; platform independent.
Just the ticket, huh? Well, if it was that easy, I wouldn’t be writing a blog post would I? Haha!
The Work
I grabbed the download from SourceForge and proceeded to build jcrawler.
You need ant, too. But that’s easily fixed.
The build completed and I was ready to slam my Seaside apps and its only been a couple of minutes! But run.sh failed:
Exception in thread “main” java.lang.UnsupportedClassVersionError: com/jcrawler/Main (Unsupported major.minor version 49.0)
It turns out that you must use JDK 5.0. Another download and some monkey business with my environment variables:
export JAVA_HOME=/home/dhenrich/jdk1.5.0_14
export PATH=$JAVA_HOME/bin:$PATH
and we’re off to the races. I launched jcrawler against:
a variant on WACounter running on my copy of the appliance.
The Problem
Things appeared to running okay. jcrawler was spinning away dumping log entries like the following to stdout (sorry about the line wrapping):
2568 [THREAD#93 CREATED 10:40:01::602] INFO com.jcrawler.UrlFetcher – Fetching URL http://172.16.172.138/seaside/examples/persistence/serial?
_s=lKtxmydVdpOJAjpt&_k=ggcZGlQC&1
However, as I interactively poked at rcTally, I noticed that jcrawler wasn’t hitting the + + or – – links, because the shared value was not getting updated.
After an excruciating amount of debugging, I noticed that the URLs extracted from the web page contained the sequence ‘&‘ instead of ‘&‘…geez it has been just about as hard to get WordPress to display the dang ‘&‘ string in my post (can’t use rich editor) as it was to find the problem in jcrawler (sorry about line wrapping):
http://172.16.172.138/seaside/examples/persistence/serial?
_s=lKtxmydVdpOJAjpt&_k=ggcZGlQC&1
The Fix
- Download an HTML Parser from SourceForge.
- Copy the jars from the HTML Parser into jcrawler:
cd /home/dhenrich/htmlparser1_5/lib
cp *.jar /home/dhenrich/jcrawler/lib - Edit the jcrawler source and insert the following line after line 120 in com/jcrawler/UrlFetcher.java (in the jcrawler src directory) to convert the encoded HTML:
content = org.htmlparser.util.Translate.decode(content);
- add htmlparser.jar to the list of jars in run.sh (in the jcrawler misc directory).
- Rebuild jcrawler and you are off to the races!
The Payoff
At the end of the day, you’ve got yourself a version of jcrawler, that can be used to randomly poke around in the nooks and crannies of your Seaside application and give it a pretty thorough workout.
As I work on the GemStone examples, I’ll learn more about jcrawler’s quirks and features, but for now it does pretty much what I need.
If there’s another load tester out there that can crawl through a Seaside website, I’d appreciate hearing about it.
Version 1.0beta6 of the appliance is rolling off the assembly line and that new software smell is once again wafting through the hallways of our Beaverton office. If you are using an appliance that is older than 1.0beta5, then you should contact us to get download instructions for 1.0beta6.
If you haven’t played with the appliance yet and have 64bit hardware, drop us an email to get download instructions, you should also read the Terse Guide to GLASS Tools.
On the development front, I am busy getting a port of SourceSource 2 running on GemStone. SourceSource 2 is Philippe Marschall’s port of SqueakSource to Seaside2.8 and Magritte. When I’m done I think that this will be a good example of what types of things need to be done to port a Squeak Seaside app to GemStone.
Oh, and don’t forget to sign up for our GLASS Beta mailing list.
Like the Siberian Express, James Foster will be blowing into the Northeast early next week. James will be talking about GLASS:
While the Seaside framework elegantly addresses HTML generation and application flow-of-control issues, it still leaves challenges for the developer–including persistence, multi-user coordination, and scaling. With typical solutions (including object-relational mapping, external files, and multiple images) the “pure objects” experience of Smalltalk is compromised. In this presentation we will demonstrate GLASS (GemStone, Linux, Apache, Seaside, and Smalltalk), a stack (analogous to LAMP) that provides a robust environment for deploying sophisticated, dynamic web applications that can scale.
Having lived for a while in Fargo, North Dakota, James is no stranger to winter weather and I understand that he is prepared to hire a team of huskies if necessary. So, if you are starting to get cabin fever and a trip to the Seaside sounds good, then it’s time to get out your Mukluks and mush on over to one of the following Smalltalk User Group meetings:
- Toronto Smalltalk User Group – February 4, 2008
- Ottawa Carleton Smalltalk Users Group – February 5, 2008
- New York City Smalltalk Users Group – February 6, 2008
BTW, James just might have a copy or two of the latest appliance.
(gem)Stone Soup 
