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
On Mon, Sep 10, 2001 at 03:06:13PM -0600, Eric Scharff wrote:
> As a user of a Unix Swiki server and Mac browsers, I've not experienced
> any problems that others seem to be reporting with uploading.
>
> It would seem that a more enhanced form of collaborative debugging would
> be helpful in isolating this problem. In particular, it'd be good to know
> where in the process things are failing.
>
> I don't know where to start, but perhaps it would be possible to annotate
> the uploading code to print some verbose logging to a file. From those
> logs, it may be easier to find the idiosyncrasies of the different
> browsers.
>
> I'll see what I can come up with,
>
> -Eric
>
