[Seaside] Interesting Comet failure - should it be more defensive?
tamackinnon at gmail.com
Fri Aug 20 06:46:35 UTC 2010
This is an interesting continuation of my "Connection Closed" post - but
this piece sits on the Comet side.
Background: I've been running Pharo Seaside3.0rc3 on my laptop and
leaving it running in the background while I read about things, browse
the web and suspend my laptop from time to time etc.
Things have been running well for a day, however this morning I noticed
two walkbacks in my image, and the root cause seemed to be the
Socket>>waitForDatFor: method. (which I can understand if I have
suspend/resumed my laptop)
However if I look at the failure - should Comet be a bit more defensive
in the following code?
self session application cache
notifyRetrieved: self session
key: self session key
The session application can be nil - and hence a DNU on #cache.
This is recent update Lukas added for a few us playing with Comet (which
has been working well in my testing).
In #push: he added
ifTrue: [ self notifySession ].
And this is where I've hit the problem. It could be that this is an
artificial example (given my suspend/resume scenario) - but then again,
could a session expire and give a similar situation?
I can imagine a workaround could be something like:
ifTrue: [ success := self notifySession ].
And then notifySession could start with:
self session application ifNil: [ ^false ].
But is this a legitimate fix?
Here's the full trace:
 in  in CTPusher>>push:
 in CTPusher>>push:
 in Semaphore>>critical:
More information about the seaside