Skip to content

Conversation

@CMogilko
Copy link
Member

As discussed in #420 , now RunOpts contains Context param, which affects all the query including reading from cursor. If context deadline exceeds stop-query will be sent.
If there is no context, then it will be formed from ConnectionOpts socket timeouts.

@CMogilko
Copy link
Member Author

Hi, is there anyone to merge/review this PR?

@CMogilko
Copy link
Member Author

Is anybody here?

Copy link
Collaborator

@dancannon dancannon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks for spending the time working on this (sorry for taking so long to review)! I left a couple of comments, let me know what you think.

"github.com/Sirupsen/logrus"
"github.com/cenkalti/backoff"
"github.com/hailocab/go-hostpool"
"golang.org/x/net/context"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend using the built-in context package.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the libraries use x/net/context, such as grpc-go, I'm not sure about old version of go, It can be difficult to pass x/net/context to context argument.

}

func (c *Connection) contextFromConnectionOpts() context.Context {
sum := c.opts.ReadTimeout + c.opts.WriteTimeout
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a little worried that this behaviour might be a little unexpected, I think it might make more sense to keep the previous behaviour if no context is passed to a query (I am just trying to think about existing code that might be affected)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previous behaviour is a quite useless. If server has continuous queries flow, socket's deadline updates every time so that even first query will not timeout never due to this reason. For me it seems like a bug.
And this is unexpected if you don't know that timeouts from config are just passed to socket.
The new behaviour is that every query ends not more than read+write timeout.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok fair enough, I am still a little worried about changing the existing behaviour but hopefully the new behaviour should not cause too many issues.

@dancannon dancannon merged commit e31dda1 into rethinkdb:master Aug 20, 2017
@CMogilko
Copy link
Member Author

Thanks. How about new tag? v3.0.3? for gopkg.in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants