[Seaside] Interesting Comet failure - should it be more defensive?

TimM 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:

UndefinedObject(Object)>>doesNotUnderstand: #cache
[] in [] in CTPusher>>push:
[] in CTPusher>>push:
[] in Semaphore>>critical:

More information about the seaside mailing list