aboutsummaryrefslogtreecommitdiffstats
path: root/rpc/notification_test.go
diff options
context:
space:
mode:
authorFelix Lange <fjl@twurst.com>2016-08-05 03:18:13 +0800
committerFelix Lange <fjl@twurst.com>2016-08-06 02:48:33 +0800
commitf5f042ffdc9fed3094b86f3dbbc85bb63a4f9537 (patch)
tree2c7fc00059c94a9178b6e75e29f31a3cacc2b68b /rpc/notification_test.go
parent464660651ddf7e8938a0fbb03f140502180a8062 (diff)
downloaddexon-f5f042ffdc9fed3094b86f3dbbc85bb63a4f9537.tar.gz
dexon-f5f042ffdc9fed3094b86f3dbbc85bb63a4f9537.tar.zst
dexon-f5f042ffdc9fed3094b86f3dbbc85bb63a4f9537.zip
rpc: ensure client doesn't block for slow subscribers
I initially made the client block if the 100-element buffer was exceeded. It turns out that this is inconvenient for simple uses of the client which subscribe and perform calls on the same goroutine, e.g. client, _ := rpc.Dial(...) ch := make(chan int) // note: no buffer sub, _ := client.EthSubscribe(ch, "something") for event := range ch { client.Call(...) } This innocent looking code will lock up if the server suddenly decides to send 2000 notifications. In this case, the client's main loop won't accept the call because it is trying to deliver a notification to ch. The issue is kind of hard to explain in the docs and few people will actually read them. Buffering is the simple option and works with close to no overhead for subscribers that always listen.
Diffstat (limited to 'rpc/notification_test.go')
-rw-r--r--rpc/notification_test.go4
1 files changed, 4 insertions, 0 deletions
diff --git a/rpc/notification_test.go b/rpc/notification_test.go
index 280503222..52352848c 100644
--- a/rpc/notification_test.go
+++ b/rpc/notification_test.go
@@ -34,6 +34,10 @@ type NotificationTestService struct {
unblockHangSubscription chan struct{}
}
+func (s *NotificationTestService) Echo(i int) int {
+ return i
+}
+
func (s *NotificationTestService) wasUnsubCallbackCalled() bool {
s.mu.Lock()
defer s.mu.Unlock()