CLOSE_WAIT sockets, a serious Swazoo bug

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

CLOSE_WAIT sockets, a serious Swazoo bug

Paolo Bonzini-2
Hi Janko,

a user of GNU Smalltalk found a serious bug in Swazoo 2.2.  To reproduce
the bug, open any Swazoo page and close the browser.  Running netstat
will show sockets in CLOSE_WAIT state.  Repeating will show more sockets
in this state.

The problem here is that when the client closes the socket, this
condition is returned by SwazooStream as a SwazooStreamNoDataError
exception; at this point, the stream should be closed on the Swazoo side

However, it is not because of this:

        [[      [ [true] whileTrue:
                       [self getAndDispatchMessages.
                       Processor yield]
             on: Error
             do: [:ex | "just ignore"] ]
        ifCurtailed: [
            (Delay forMilliseconds: 50) wait. "to finish sending, if any"
            self close] ].

Ignoring the exception causes #getAndDispatchMessages to sit forever
waiting for I/O (not busy waiting, at least on GNU Smalltalk) while the
socket is left open.

I changed this to

     [[[true] whileTrue:
            [self getAndDispatchMessages.
            Processor yield]]
                    [self close]]
        on: Error
        do: [:ex |
           (Delay forMilliseconds: 50) wait. "to finish sending, if any"
           self close]].

and it fixes the bug.

By the way, I'm not sure about the need for those delays either.
There's one here and one in #getAndDispatchMessages.  They don't seem to
be necessary on GNU Smalltalk.

Finally, here we're using #on:do: directly rather than the Sport
wrapper.  I think we should do this uniformly in Swazoo for this
particular case, since exceptions are now portable and we're relying on
the ANSI #ifCurtailed: message anyway.



Swazoo-devel mailing list
[hidden email]