Hi Lukas,

My best guess (from afar) is that the connection is closed immediately after
the reply has been sent and that something is going wrong in the handling of
this situation. E.g., consider the following code:

Socket initializeNetwork.
port := 12346.

"create client and server"
server := Socket newTCP.
server listenOn: port.
client := Socket newTCP.
client connectTo: NetNameResolver localHostAddress port: port.
[client isConnected] whileFalse:[(Delay forSeconds: 1) wait].

"send request"
client sendData: 'Hi there'.

"handle on server"
request := String new: 100.
sz := server receiveDataInto: request.
request := request copyFrom: 1 to: sz.
request = 'Hi there' 
	ifFalse:[self error: 'Something went wrong'].

"---> send response and immediately close <---"
server sendData: 'Response'.
server close.
[server isConnected] whileTrue:[(Delay forSeconds: 1) wait].

At this point, the server closed the connection whereas the client hasn't
done anything yet. Depending on the VM implementation this can cause severe
trouble. You may want to check (on varying platforms) what the results of
the following are:
					"Win32"
a) client statusString.		 'connected'
b) client getData.		 'Response'
d) client statusString.		 'otherEndClosedButNotThisEnd'

And to answer your specific questions:
> 1. Are the sockets in Squeak at all being able to be used 
> from different threads?

Yes they are. Unless you attempt to use the same socket simultanously from
different threads there is no problem. If you do the latter then you have
the "common" issues of synchronizing access to a shared resource from
different threads.

> 2. Could it be that the production server is too fast? We didn't have 
> those problems on the development machines (macintosh and windows).

It could be. The above example simulates an infinitely fast server which
replies before client has a chance to look at it.

> 3. Should we try another VM, another image, another postgres client?

First of all, run the above example and see what this gets you. It _may_ be
that the VM is merely reporting that the "otherEndClosedButNotThisEnd" and
that your code deduces from this that there is no readable data on the
socket (e.g., #isConnected will return false which in turn may screw
#getData and friends). In this situation you _may_ still be able to read
data from the socket (can't say without having tried it; but see what
#primSocket:receiveDataInto:startingAt:count: reports) and simply work
around this problem.

> 4. Is there anybody in this mailing-list able to help with 
> that kind of problems? We are lost and are really fed up with
> those Squeak sockets! We would be even willing to pay the one
> that is able to solve the problem.

If the above solves your problem make a donation to Squeak e.V. (heh, heh)
It's even tax-deductable ;-)

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Lukas Renggli
> Sent: Friday, September 12, 2003 5:19 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Socket Problems
> 
> 
> Hi,
> 
> we've got a production server for an insurance company 
> running a Squeak 
> 3.5 image on the 3.6b6 VM on Debian Linux. Unfortunately there are 
> mysterious problems with the sockets when accessing PostgreSQL from 
> within Squeak. We wrote workarounds, that just retry if a 
> connection is 
> failing, but this isn't helping much anymore. 
> 
> As it is a critical business application the client is not only 
> complaining but even beginning to sue for damage, that we are 
> unable to 
> afford as a little internet agency! This means that *we won't be ever 
> able to use squeak again* and that we have to go back to 
> other solutions 
> like Python or ASP.
> 
> To the problem: we've got a couple of connections being used by 
> different threads executing queries on postgres. During heavy 
> load - and 
> this is where most of the time the problem shows up - there are about 
> 300 queries executed sequentially on one connection by one 
> thread. Most 
> often, the connections are suddenly closed, even before 
> Squeak starts to 
> wait for the data.
> 
> This was the part, to stress the *urgency* and to explain the 
> background 
> for the following questions:
> 
> 1. Are the sockets in Squeak at all being able to be used 
> from different 
> threads?
> 
> 2. Could it be that the production server is too fast? We didn't have 
> those problems on the development machines (macintosh and windows).
> 
> 3. Should we try another VM, another image, another postgres client?
> 
> 4. Is there anybody in this mailing-list able to help with 
> that kind of 
> problems? We are lost and are really fed up with those Squeak 
> sockets! 
> We would be even willing to pay the one that is able to solve the 
> problem.
> 
> Lukas
> 
> -- 
> Lukas Renggli
> http://renggli.freezope.org
> 
>