How to waste less time debugging a Seaside/Glorp application


Yesterday I packaged my Seaside Application for the first time on VA Smalltalk 8.5.2 and deployed it to a staging server.

And promptly – as expected, I got some errors: The first few were easy to find. One of them being a missing rule in AbtXDSingleImagePackagingRule (or some superclass) to include the new EsTimeZone code. That could be fixed by hand.

But this morning I spent quite some time searching for a problem in the walkback.log that didn’t exist. And this post is mostly intended for myself to remember next time. But it might also save you some time. The second purpose of this post (or, to be exact, the next one) is to underline why I think the VAST port of Glorp has a lousy adaption of error handling.

But let’s start at the beginning: My image crashed as soon as a web user logged on to the web application. The image exited with Error code 60 and wrote a walkback log. So far, so good. The first thing this tells me is that my error handling code is not perfect yet, because I should have seen an error page instead of an HTTP-503.

So I started reading the walkback. My usual way of doing so is to start with the beginning of the walkback:

Walkback at 11:25:20 on 12.12.2012
Database error: 
[] in AbtHeadlessRuntimeStartUp class>>#outputWalkback:process:  
    receiver = AbtHeadlessRuntimeStartUp  
    arg1 = 'Database error: '  
    arg2 = Process:Dispatch worker: 8{running,3}  
    temp1 = 'walkback.log'  
    temp2 = a CfsWriteFileStream
BlockContextTemplate(Block)>>#valueWithErrorHandler:oldHandler:onReturnDo:  
    receiver = [] in AbtHeadlessRuntimeStartUp class>>#outputWalkback:process:
   ... and so on

So one thing was for sure: this is another one of those useless error messages that come from Glorp. Unfortunately, I decided to skip step two of my usual walkback reading procedure: start scrolling down to some pattern I feel looks like the cause of the error. In case of Glorp-related problems, I have learned that this step doesn’t work well. So I switched to step three: read the walkback bottom up.
I know that is a warning signal, but I ignored it.

Then I came to this part of the walkback:

BlockContextTemplate(Block)>>#when:do:
  receiver = [] in WAServerAdaptor>>#handleRequest:
  arg1 = Exception: (ExWAResponseNotification) A notification has occurred
  arg2 = [] in WAServerAdaptor>>#handleRequest:
  temp1 = an Object
  temp2 = nil

And that’s where I started wasting lots of time. I should have skipped this, but instead I tried to understand what’s going on. An Exception that was thrown somewhere in somewhere in the request/response handling code of Server Smalltalk, that could possibly have lead to an error that looks like a Database Error. Maybe I was missing some more classes in the packaged image, some ServerAdaptor or whatever. So I jumped back and forth between the Class Browsers on classes like WAServerAdaptor, SstHttpInvokerServlet, WACurrentRequestContext and friends on one side and the packaged image contents tool in my😄 packaging image on the other side.
All the code that seemed to be needed was there…
Diving up the walkback log I finally came across the method WAServerAdaptor>>#handleRequest: which looks like this:

handleRequest: aRequestContext
	"Pass the request context to the appropriate request handler."

	[ self requestHandler handle: aRequestContext ]
		on: WAResponseNotification
		do: [ :n | "got a response" ]

So this method simply ignores that exception and goes on. Perfect. I knew I had read about the interesting use of exceptions in Seaside but had never actually seen it before. This whole exercise had taken about an hour or so, simply because I mistrusted my packaging result. I was hunting for an exceptions that is not an error, but just a sign that all is well and good.

This brings us to the second lesson of this post (Remember, the first one was to be warned whenever you think you have to start reading a walkback from the bottom up): ignore the Seaside Notification thing in Walkbacks. Don’t even waste a second thinking about it. It’s not important, just scroll futher up! There’s nothing to see here.

I felt like an idiot, but had learned a lesson. I’ll continue this story in another post soon….

3 thoughts on “How to waste less time debugging a Seaside/Glorp application

  1. Philippe,

    Well, it looks as if it ignores it.
    Or what exactly would you think code like this does:

    [self doSomething]
    on: Error
    do: [:exception| “Here is nothing more than some comment”].

    But of course it is not ignored in the sense that Seaside doesn’t care about it. It’s just that it doesn’t do much with it in this very method. If I hadn’t heard about those kinds of exceptions/notifications in Seaside, I’d probably have spent a lot more time on trying to understand what is going on there.

    If my post sounded like I’m blaming you guys for my journey in the debugger, then I made it sound wrong. I just wanted to write down what I’ve learned about the notifications so that I will remember it.

    Joachim

  2. The Seaside code posted here does not ignore exceptions. WAResponseNotification is a special notification that signals to the framework to abandon all further request processing and send the response as is. We could (and did) use a continuation for this, but it’s less portable.

Comments are closed.