Sounds logic, It explains the incidental upload succes on the moment my
machine hicks-up?
But how can you explain the differences between (always) succesful using
different browser-clients like Netscape 6.1 and Opera 5.12 versus the
unsuccesful IE5.5 client, in combination with the same windows98 and/or
NT-Swiki-server?
(And as you see in the email of Cena, Resty the pattern is even more weird.)
What did you change in the way upload-handling works between this and the
previous release: improve performance? so it now bites me back in my tail?
(Of course does no one with a good functioning machine want to loose this
improvement, but for the others: a button for choosing a more
time-consuming-check would be nice? again I am a user not a NT-technician:
the ideal situation for me is to have an out-of-the-box-server: no other
free server - as far as I know - does offer that yet.)
-----Original Message-----
From: Bolot Kerimbaev [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 11, 2001 8:08 AM
To: [EMAIL PROTECTED]
Subject: Re: [pws] Windows Uploading Blues
I'm not entirely sure what causes upload problems, but some of the
symptoms indicate that it could have something to do with the speed of
the processor and WinSock implementation.
Observation 1: On Win2K, Swikis are fairly unstable. I wasn't able to
fix them entirely by just tweaking the Squeak-level code.
Observation 2: Raymond's machine got the CPU upgraded, and the
previously good NT started behaving badly.
Today I replicated the problem by trying to upload from IE5.5. I
turned off error supression (in Preferences, uncheck standaloneServer).
In the Debugger I discovered that there wasn't enough data read from
the socket, so I forced some data to be read (sockStream pvtGetData)
and restarted the context in which the HttpMultiPartChunk was being
read. The upload proceeded successfully.
Curiously, writing to Transcript for logging purposes will eliminate
this problem (I didn't check, but read on). Transcript operations are
very slow, so they may provide sufficient delay in critical points for
this error to be eliminated, at the cost of performance.
The way this can be fixed (even from the image-level) is by reviewing
the logic that deals with the socket/SocketStream. Particularly,
dealing with extreme situations (such as data expected but not
available yet, or data interrupted but connection still open).
Bolot
