It is not uncommon for a type to contain methods that do not conform to the method signatures required by net/rpc.

What's an example of case where that's acceptable to ignore the warning?

What's an example of case where that's acceptable to ignore the warning?

The type which has one or more RPC method signature conforming methods may also be implementing some other interface and hence can contain other methods. Here's a very simplified example: https://play.golang.org/p/HINYYRn1mU

That comment has bad grammar and needs fixing in any case.

The package is frozen featurewise, but I agree that log message may be spammier than needed. I have no memory of doing the review of https://codereview.appspot.com/6819081, which added the log message along with many others. @minux thought it was important to add them, so I'll pass this one on to him.

OK, sounds like Rob is OK with dropping the log statement. I will note that this makes the failure to invoke the method somewhat more mysterious, at least unexplained.

I don't think the log is necessarily needed, but I can agree to improve log message.
How about this?

diff --git a/src/net/rpc/server.go b/src/net/rpc/server.go
index a021292603..89a07fc92d 100644
--- a/src/net/rpc/server.go
+++ b/src/net/rpc/server.go
@@ -296,7 +296,7 @@ func suitableMethods(typ reflect.Type, reportErr bool) map[string]*methodType {
                // Method needs three ins: receiver, *args, *reply.
                if mtype.NumIn() != 3 {
                        if reportErr {
-                               log.Println("method", mname, "has wrong number of ins:", mtype.NumIn())
+                               log.Printf("rpc.Register: method %q has wrong number of parameters, got: %d\n", mname, mtype.NumIn())
                        }
                        continue
                }

If we apply changes like the above patch, there are other things we need to fix.

That seems fine to me. Please send a CL.

Change https://golang.org/cl/87335 mentions this issue: net/rpc: improve error report messages

@robpike Is it OK to close this issue?
If we think that this problem was inherently solved by having the error message become more detailed, I would like to close it.

Well, https://golang.org/cl/87335 just changes the log message but doesn't remove it. It did not fix the issue reported in any way.

It's really annoying and misleading to see these many log messages logged by standard library. The net/rpc package is "frozen" only featurewise.

I can send a patch to remove the log if you guys agree.

I found this issue because I just ran into this myself. I have a type which I want to expose as an RPC endpoint, but it has additional exported methods. The mandatory emission of logs is bad ergonomics here, and goes against the documentation, which says:

Only methods that satisfy these criteria will be made available for remote access; other methods will be ignored: [...] list of criteria

Emitting a log is not entirely ignoring other methods.

From this issue it sounds like @robpike was for reverting the mandatory logging, but then the issue got auto-closed after only the error message part changed.

I'm reopening the issue, and will be happy to implement the change. Are there any objections?

@minux

@eliben Perhaps just go ahead and implement the fix?

@neild for thoughts

Removing the message seems fine to me.

Change https://golang.org/cl/350009 mentions this issue: net/rpc: remove warnings on incompatible methods at registration

Thanks!