Comment 1:

Correction: use the attached (modified) jsonrpc.py, which closes the connection at the
end. Expected output: none. Actual output, usually none, but sometimes "rpc: rpc: server
cannot decode request: read tcp [::1]:52123: connection reset by peer". Less often seen
is "rpc: writing response: write tcp [::1]:58961: broken pipe"

Attachments:

1. jsonrpc.py (382 bytes)

Comment 2:

Status changed to WaitingForReply.

Comment 3:

I think this is working fine at tip.
I added some prints to ServeCodec
diff -r 6b38b2ad3d41 src/pkg/net/rpc/server.go
--- a/src/pkg/net/rpc/server.go Wed Nov 09 16:01:55 2011 -0500
+++ b/src/pkg/net/rpc/server.go Wed Nov 09 16:07:19 2011 -0500
@@ -391,10 +391,13 @@
 // ServeCodec is like ServeConn but uses the specified codec to
 // decode requests and encode responses.
 func (server *Server) ServeCodec(codec ServerCodec) {
+println("serving", codec)
    sending := new(sync.Mutex)
    for {
+println("read...", codec)
        service, mtype, req, argv, replyv, keepReading, err := server.readRequest(codec)
        if err != nil {
+println("read request", codec, err.Error())
            if err != io.EOF {
                log.Println("rpc:", err)
            }
@@ -410,6 +413,7 @@
        }
        go service.call(server, sending, mtype, req, argv, replyv, codec)
    }
+println("close", codec)
    codec.Close()
 }
 
When I run your program and jsonrpc.py against it, it prints:
$ python2.6 jsonrpc.py
{"params": [{"First": 99}], "method": "RpcOps.AddOne", "id": "1"}
serving (0xf84001efc0,0xf840051000)
read... (0xf84001efc0,0xf840051000)
read... (0xf84001efc0,0xf840051000)
read request (0xf84001efc0,0xf840051000) EOF
close (0xf84001efc0,0xf840051000)
$ 
You say that you are using release.r57, and it is definitely
not fixed there.  You also say that you checked tip. 
What does checked mean?  Did you run the code or just look
for your fix?  Your fix is strange - it turns any non-EOF
error into ErrUnexpectedEOF, losing information - and we 
solved the problem by adding the additional keepReading bool
return value instead.
Can you please try running your program at tip?
I also tried running your jsonrpc.py with the sendall
argument changed to 'This is not JSON!'.  It prints a
single error about not being able to decode and then
closes the connection gracefully.
Russ

Comment 4:

Sorry - I did not modify the details from issue #1828, so the release information was
wrong. I am indeed running at tip - attached is a main.go fixed again for the latest
changes, and my system information is below. Sorry for not filing properly.
Again, it works fine most (=80%) of the time, but it prints inconsistent error messages
the other 20%. Some experimentation shows that it's more likely to go the error route
when the system is under moderate load.
What operating system are you running?
# Archlinux.
sh-4.2$ uname -a
Linux jagadai 3.1.0-ARCH-09552-g82f614f #47 SMP PREEMPT Sat Nov 5 22:50:26 EDT 2011
x86_64 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux
Which compiler are you using?
sh-4.2$ 6g -V
6g version weekly.2011-11-09 10399+
What operating system are you running.
sh-4.2$ hg id
b23afd541c82+ tip

Attachments:

1. main.go (723 bytes)

Comment 5:

Labels changed: added priority-later.

Comment 6:

Labels changed: added priority-go1.

Comment 7:

Owner changed to builder@golang.org.

Comment 8:

Status changed to Accepted.

Comment 9:

Labels changed: added go1-must.

Comment 10:

I looked into this.  If I start your server and run the python script 100 times, then I
do in fact get the occasional error you reported, but that is not surprising: the python
client has hung up unexpectedly, and that is being reported.  Exactly whether the error
gets to the server in time depends on TCP connection timing, I suspect.
Regardless of whether the error gets printed, the connection close does seem to be
processed correctly.  After running a few hundred runs of the python script, I ran
killall -abrt a.out and there were no unexpected goroutines, just main (listening) and
the epoll goroutine.
So I think this is working correctly.

Status changed to WorkingAsIntended.