[squeak-dev] Stalling own SqueakSource instance

Dear all,

I’m experiencing recurrent stalling when someone is uploading
to my SqueakSource instance. This is producing a 100% processor
load on my machine. Looking at the Process browser, many (10+)
processes are waiting (by Semaphore) for one process, where an
HTTP-Put request is processed. This process is “waiting for data,”
as it seems to me. It stalls at Socket>>waitForDataIfClosed:
   Can anyone give me a hint? I might provide further data (e.g.,
stack trace), if necessary.

So Long and thanks,
        -Tobias Pape

2009/5/12 Tobias Pape <[hidden email]>:
Do you run an old Squeak (<= 3.8)?

Cheers
Philippe

Hello,

Am 2009-05-13 um 07:01 schrieb Philippe Marschall:

> 2009/5/12 Tobias Pape <[hidden email]>:
>> Dear all,
>>
[…]
>
>
> Do you run an old Squeak (<= 3.8)?

Jepp, its 3.8 at level #6665.
It has been running for about 2..3 Years now, tho. Mostly flawlessly.
Yet, it began to stall about a month ago.

So Long,
        -Tobias

sounds like

http://bugs.squeak.org/view.php?id=6581


On 13-May-09, at 3:12 AM, Tobias Pape wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Hello John,

Am 2009-05-13 um 21:11 schrieb John M McIntosh:

> sounds like
>
> http://bugs.squeak.org/view.php?id=6581


Unfortunately, this doesn’t seem to be the case.
I do not experiences this particular symptoms:
- In the case of 100% cpu usage, I’m not able to
   VNC the image anymore.
- If I’m already connected by VNC, moving the mouse does
   not help.
- It only happens in case of a HTTP PUT (i.e., pushing a new
   mcz) that happens to be aborted by the use.

Debugging such a process revealed the following:
- in WAKom>>process: the PUT-specific beaviour is called,
        i.e., the PUTData is tried to be retrieved
(*in the meantime, the “other end” aborts the upload, thus closing
        the connection. The Socket is still connected on “out end”, though.)
-- we are now in SocketStream>>next:
--- the End of the Stream is tested (#atEnd)
-- because “our end” is still connected (I think) and we did not receive
        all data (because the connection was closed on the other end) we
        are not atEnd and there seems to be data available
--- thus we reach SocketStream>>receiveData
---- and Socket>>receiveDataTimeout:into:
----- and Socket>>receiveDataTimeout:into:startingAt:
----- there, the line
! self waitForDataFor: timeout ifClosed: [] ifTimeOut: [].
        occurs.
-------Socket>>waitForDataFor:ifClosed:ifTimeOut:  determines that the
  Socket is closed (in contrary to #atEnd above), yet the given
        closedBlock is empty
----- thus, in and Socket>>receiveDataTimeout:into:startingAt: the  
primitve
        for reading data is called, where 0 is returned
--- therefore, in SocketStream>>receiveData the bytesRead is 0 and
        inStream is not altered
-- we are now back in SocketStream>>next:
        atEnd, again, says that the stream is not at end and still connected.
        and since the inStream is unaltered, the second condition states that  
there
        would be data to read.

I consider this a vicious circle.
   The only cure I found  up until now was manually terminating these  
processes.
Can somebody confirm this? I’d be grateful for any response.

So Long,
        -Tobias

On Thu, 14 May 2009 10:15:37 +0200, Tobias Pape wrote:

The above (re. in contrary to #atEnd, etc) reminded me of this one,

- http://bugs.squeak.org/view.php?id=6951

perhaps some of the socket states/method comments are out of sync?

/Klaus

> So Long,
> -Tobias


--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

Hello Klaus,

Am 2009-05-14 um 13:18 schrieb Klaus D. Witzel:

[…]
> The above (re. in contrary to #atEnd, etc) reminded me of this one,
>
> - http://bugs.squeak.org/view.php?id=6951
>
> perhaps some of the socket states/method comments are out of sync?

This indeed looks like the problem I am experienceing.
Yet, the code of the respective methods mentioned seems to be
unchanged. I compared to a recent 3.10 and did not
notice functional changes.
  Especially, waitForDataIfClosed is still called with to empty
Blocks.
  Is some advance concerning this bug to be expected in the near
future?

So Long,
        -Tobias Pape

Hi Tobias,

on Thu, 14 May 2009 17:29:01 +0200, you wrote:

Yup, this waitForDataFor: timeout ifClosed: [] ifTimeOut: [] looks  
strange, since until that point in time no one (especially no one who  
sends #receiveData*) might ever have accessed the socket other than for  
status *queries*.

If you can *still* reproduce your original problem then I'd suggest to  
#waitForData* only if zero bytes where seen, that is, do the following  
small change:

1) let #receiveDataTimeout:into:startingAt: first read and memorize num  
bytes

2) then, if numbytes was 0, do #waitForData* and redo #receiveData*

I know that it is complex to provoke the above, just for testing, but you  
seem to have a problem at hand which could get us one step closer to a  
possible solution.

Between 1) and 2) a status change may be reported by the VM/plugin to the  
socket, which otherwise might not have been the case (in the way mentioned  
above).

If I was unclear then please ask.

>   Is some advance concerning this bug to be expected in the near
> future?

Dunno, there was some discussion but googleing didn't find any patch or  
suggestion.

/Klaus

> -Tobias Pape