Why does channel's query api get bus error after multiple queries

15 views
Skip to first unread message

Jasper Wu

unread,
Dec 10, 2017, 7:14:55 PM12/10/17
to grpc.io
I'm working on a async client that keeps on sending tasks to servers. To make it efficient and fail-tolerant, I maintain server status by constantly checking if the channel is working.

However, for all channel query apis, I've tried
channel::GetState(), channel::WaitForConnnected(T deadline), etc...
All of them gives segfault after multiple queries.
Does anyone know why? And how should I query about channel connectivity or server up/down info?

I read connectivity-semantics-and-api.md and understand that connection status will become "TRANSIENT_FAILURE" if the server is down.

My goal here is to know if that server is later up so that I can distribute tasks to it. I understand that I can simply keep sending messages to potentially up servers and grpc will keep reconnecting if the server is down. But I keep tasks as a pool and send the task while removing it from the pool. And later if deadline is exceeded, I will then added back to the pool. So if I keep sending the task to an already-known-failed server, I would waste time resources by keep sending tasks. So any other idea for implementing this?

I'm not sure if I can my points clearly. My project is kind of involved and yet I'm a newbie to this area, sorry and thanks for reading!!

Jasper Wu

unread,
Dec 10, 2017, 11:21:03 PM12/10/17
to grpc.io
Can I delete this post? I found out my own mistake. I stored shared_ptr to a data structure as shared_ptr&, and since the original share_ptr is out-of-scope, the object has reference 0 and thusly deallocated, which is why there is segfault.

I now store shared_ptr as shared_ptr, copied the whole shared_ptr into the data structure as the new container, and now problem is fixed. & is good for performance, but watch out because it's not a reference to the actual object and does not count as shared_ptr count!.
Reply all
Reply to author
Forward
0 new messages