Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application aborted #91

Closed
fcrisciani opened this issue Nov 15, 2017 · 4 comments
Closed

Application aborted #91

fcrisciani opened this issue Nov 15, 2017 · 4 comments
Assignees

Comments

@fcrisciani
Copy link

I see this error:

E1115 06:01:59.641457364     198 completion_queue.cc:67]     assertion failed: !uv_is_active((uv_handle_t *)&prepare)

This is the line: https://github.com/grpc/grpc/blame/v1.7.x/src/node/ext/completion_queue.cc#L67

What I'm doing differently from before is to call the client.waitForReady every time before calling an RPC method.

Any idea?

@hhamilto
Copy link

I'm having the same issue -- had to downgrade to 1.6.6

@fcrisciani
Copy link
Author

@hhamilto do you use a similar approach to guarantee that the connection is established before issueing an RPC call?
I have a series of microservices in node all interacting with grpc. I did not find a good way to track the connection status and restart it if drops, so I was opting for triggering the waitForReady before each call. Do you use any other approach? (I was also trying to inspect the channel connection status and eventually create a new client but anyway you should call the wait for ready on that one too)

@hhamilto
Copy link

I'm not calling client.waitForReady directly in my code, but I am calling grpc.waitForClientReady in different places.

I haven't come up with anything I consider a completely sure way of restarting the connection if it drops, but I do listen for the error event on the connection and restart if the code is 14:

		connection.on('error', function(err){
			if (err.code === 14) {
			    // ... reconnect code

@murgatroid99 murgatroid99 self-assigned this Nov 16, 2017
@murgatroid99
Copy link
Member

Thank you for bringing this to our attention. That assertion itself is incorrect due to a recent change that makes waitForReady work as intended. We will publish a patch release soon with the fix.

@lock lock bot locked as resolved and limited conversation to collaborators Sep 29, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants