[Update: Thinking about this a little more, this post has a misleading title. This is very likely not to be a Seaside issue at all, but one of VA Smalltalk’s WASstServerAdaptor, which, if started/registered too late (whatever too late may be), doesn’t get realized by Apache. So the title of this post should rather be:
VA Smalltalk: registering a WASstServerAdaptor too late leads to an HTTP 503 error
From time to time, I learn something new. Sometimes it’s fun, sometimes it’s less pleasant. And sometimes it feels like wasting lots of time.
Yesterday, I lost a lot of time, and I ended up only understanding the problme and found a way to circomvent it. But I don’t really understand why things happen the way they do. So if a kind soul out there reads this and understands the reasons for the problem, I am grateful for helpful comments😉
So here is the story:
During startup of our Seaside Application, we load a lot of read-only data into memory. This takes a while, almost half a minute. During that time, the server shouldn’t really accept user logins because if that data isn’t pre-loaded, the server can’t really do anything useful for users – other than write friendly walkbacks that keep our developers happy😉
Since the main purpose of our Server Application is not being started, but to run and do useful stuff, and since under normal circumstances a restart of the application is not necessary for days, sometimes even weeks in a row, we just tried the simplest thing that could possibly work. We would just start the WAServerAdaptor after the pre-loading of data is finished. In pseudo-code the sequence looks like this:
self loadAllNecessaryStuff. self startSeasideAdaptorOnPort: xxxx. WAAdmin register: MyApp asApplicationAt: 'TheBestStuffYoullEverSee'.
We thought this is a clever idea. Users visiting our Application would see an HTTP 503 served by Apache during startup. This would be good enough, because we only restart the Application late at night under normal circumstances, and there would be only a small chance that anybody would be affected, although it did happen once or twice before.
So we started the Application, started Firefox and tried to see the results. All worked well: Apache answered an HTTP 503 Service not Available.
A bit surprising was the fact that Apache didn’t change its mind after a minute or so. Still a 503.
A look at the Application’s logfile said: the pre-loading is done, we’re ready to go!
Another minute later, Apache still was very confident in the fact that nobody is listening on port 8080. So we tried locally with curl, and there really was no answer. Looking a bit closer at the log output of the Application also gave us a bit of a shiver: the usual startup log output of the WASstServerAdaptor were missing from the log.
So we changed the startup sequence of our Application to look like this:
self startSeasideAdaptorOnPort: xxxx. self loadAllNecessaryStuff. WAAdmin register: MyApp asApplicationAt: 'TheBestStuffYoullEverSee'.
This is much better: During the pre-loading, Seaside now answers with a short message saying that
/TheBestStuffYoullEverSee is not found.
And when the pre-loading is done, users are greeted with a login page.
One day we’ll probably add a nice page saying: please wait, the server is currently starting. But for now, this is enough. This whole thing is not happening often, and we just want to avoid getting walkbacks just because somebody logged in too early, because that’s a waste of time.
So here is what puzzles me:
- What sequence of events leads to the fact that the Application is not answering request, or better: why doesnt SST register the handler?
- Is this a Seaside bug or an SST bug in VAST?
- How can we tell if registering a handler is too late? how late is too late?
- How can this be too late at all? I mean, we’re starting to listen at a port, and no matter if this happens a second after an image starts up or five minutes later, this should work, right?
Even though the matter is fixed for us now, there is some bitter taste somewhere in my throat.