Subject: Netscape SDK Socket Blocking Problem? (WSAEINPROGRESS)

From: "Vilenchik, Osnat" <[email-masked]>
Date: Mon, 28 Feb 2000 19:09:09 +0200

Hi

> We are having problems with heavy loads on the Netscape SDK. When running
> many threads (200 or so), each one issuing a search request, the socket
> layer (window sockets) starts returning a WSAEINPROGRESS error to the SDK.
> This indicates that the socket is blocked (full of pending data) and can
> not accept data for now (the condition is temporary since soon after, the
> socket gets out of the blocked mode as it sends the buffered data to the
> server). 
> 
> The SDK code (as available from Mozilla, Sdk version 3) regards any error
> from the socket layer on a write (send) as a cause for returning an
> LDAP_SERVER_DOWN error. 
> 
> This causes a problem since although the connection is not actually down,
> the Sdk says so. This results in our error recovery code being triggered,
> causing all sorts of other complications.
> 
> Question: is it really so - that once an error code (even one that
> represents a temporary difficulty) is received by the Netscape Sdk code it
> regards the connection is dead? 
> 
Did anyone had such an experience? Are you aware of any SDK which handles
such cases?

Thanx, 
Ossie Vilenchik
Office: 972-3-7655759 Fax: 972-3-6452855
e-mail: [email-masked]

---

From: Terry Lambert <[email-masked]>
Date: Mon, 28 Feb 2000 11:11:01 -0800

Vilenchik, Osnat wrote:
> > We are having problems with heavy loads on the Netscape
> > SDK. When running many threads (200 or so), each one
> > issuing a search request, the socket layer (window
> > sockets) starts returning a WSAEINPROGRESS error to the
> > SDK.  This indicates that the socket is blocked (full
> > of pending data) and can not accept data for now (the
> > condition is temporary since soon after, the socket
> > gets out of the blocked mode as it sends the buffered
> > data to the server).

This is arguably a bug in the sockets implementation; the
write attempt should be blocked until it can be successfully
completed by the operating system, instead of returning a
"try again later, I have brain damage right now" error.

Clearly, the SDK needs to work around the brain damage of
the OS on which it is expected to run (unfortunate but true,
I'm afraid).

It's terrifically tempting to "punish" the damaged OS by
spinning on the write until it can be successfully
completed... moreso because it would avoid having to write
a seperate retry latency mechanism to work around the OS
being "too busy to take commands from you right now".

Conventional "wisdom" would tell us "start another thread to
hold the retry"...

8-p

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.