I seem to have run into a problem reading data from a post
operation.  The data being posted is an XMLRPC request and the sizes
range from about 100 to 1000 bytes - i.e. not that much data, really.

Using the ns_conncptofp to copy the content to a temporary file I
routinely get the error "resource temporarly unavailable".  Which we
all know is typically cause by an i/o operation on a non-blocking
descriptor when, for some reason, reading or writing cannot be done at
that time.

I've added a bit of debugging code to track down why this is happining
and here is what I get from my log files.

[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Length 547
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Allocating space for 547 bytes
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: reading 547 bytes from socket
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockRecv: reading 16000, buffer 
2747b4, timeout 30
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockRecv: read -1, errno 11
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockWait: 30
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockWait: seting up fdset
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockWait: selecting for read
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockWait: read select done, 
result 1
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockWait: select returned 1, 
errno 0
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockWait: returning OK
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockRecv: Rereading socked 7, 
buffer 2747b4, toread 16000
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockRecv: read -1, errno 11
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Ns_SockRecv: returning -1
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: -1 bytes, Errno: 11
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Results were -1 bytes read (-1 means 
error)
[31/Oct/2001:17:34:01][11632.16][-conn1-] Notice: Results set to error message


The lines that have Ns_SockRecv or Ns_SockWait were printed from
within those functions inside of nsd/sock.c

It looks like the first recv in Ns_SockRecv is returning EWOULDBLOCK,
so we decide to call Ns_SockWait which performs a select on the
socket.  The select returns without error, indicating that one file
descriptor is ready to be read from.  Ns_SockWait then returns an OK
since select said there is data ready to be read on the socket.
However, when we then attempt the second recv in Ns_SockRecv we again
get an error EWOULDBLOCK (which is the same as EAGAIN which is ernno =
11).

What's happining here?  Has anyone seen this before?  Here is some
info on the system we are running:

~> uname -a
SunOS hostname 5.8 Generic_108528-07 sun4u sparc SUNW,UltraAX-i2

~> gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs
gcc version 2.95.3 20010315 (release)

Truthfully, this is looking like something more like a kernel or gcc
bug to me - the aolserver code seems to be ok, but I want to check
here to see if anyone else has seen this behavior.

Thanks,

Matthew

Reply via email to