[Q] [Scriptaculous and Comet] SUStream related question

> 2006/10/14, Sungjin Chun <[hidden email]>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Philippe Marschall wrote:
> > > 2006/10/14, Sungjin Chun <[hidden email]>:
> > > OOPS!, I encountered a severe problem. After I saved image(with
> > > WAListenerEncoded Running) and reopen, the image just freezed and I
> > > cannot access to the service(seaside application) nor tools.
> > >
> > > Is there any relationship between new version of seaside and this
> > > problem?
> > >
> > >> Don't know yet, but I can confirm the problem :(
> > >> Squeak image is taking up 100 % CPU.
> > >
> > >> gdb seems to indicate that it's constantly in
> > >> in WAListener>listenLoop
> > >
> > >> I'd say it's either WALinstener* or Comet related.
> > >
> > >> Philippe
> > >
> > > Thanks in advance.
> >
> > It seems that this problem is related to WAListener*, not Comet, though
> > I'm not sure. What I've tested is that stop the Comet's ping process and
> >  keep the WAListener* running, this problem just happens, even though
> > ping process(which is related to Comet) not running.
> >
> > Is this related to network initialization in squeak? I cannot figure out
> > what's wrong.
>
> WAListener does not terminate itself when it the image quits. It then
> holds an invalid socket. Compared to subclasses of WAKom this doesn't
> turn out well for subclasses of WAListener.
>
> That it runs at:
> Processor highIOPriority
> doesn't really help as well
>
> a
> WAListenerEncoded initialize.
> WAListenerEncoded39 initialize.
> was missing
>
> If you manage to execute
> WAListenerEncoded stop
> After the image startup it should be usable again.

> > There is now a class called WAListenerEncoded that has the same
> > semantics as WAKomEncoded.
>
> WAKom, WAKomEncoded, WAKomEncoded39, WAListener, WAListernerEncoded,
> WAListenerEncoded39, WAListenerPlus, WAListernerEncoded39Plus, ... ;-)
>
> Why can't we just have a conversion strategy? As far as I remember
> this conversion happens when a Kom request/response is transformed
> from/to a Seaside request/respose. So it should be easy to factor that
> out into a strategy and avoid this ugly WAKom/WAListener class
> hierarchies, no?