How to close a Client... #8

Closed
a2800276 opened this Issue Mar 29, 2012 · 6 comments

Comments

Projects
None yet
2 participants

I'm probably overlooking something, but I don't see any way to close a client and release the connections it's holding.

This would be particularly important for pipeline clients where several might be opened simultaneously.

Owner

simonz05 commented Mar 29, 2012

Hi,

I modified the example/transaction.go file to create godis.MaxClientConn + 1 go routine which each request and hold on a connection from a single client. One of the go routines might block while calling p.Exec(), but only until one of the other go routines is done reading it's replies. After the last reply is read of a connection, it's pushed back into the connection pool.

The program should output something like:

$ ./transaction 
GET foo: 1
GET foo: 0
GET foo: 2

if godis.MaxClientConn == 2.

https://gist.github.com/2242549

Hope that solves your questions.

S.

@simonz05 simonz05 closed this Mar 29, 2012

It does, thanks! But I'm still wondering how I clean up once I'm through using the Client, i.e. at what point the tcp connections in the pool are closed?

Owner

simonz05 commented Mar 29, 2012

Mhm,

Actually I noticed while reading the code, that a PipeClient always will create a new client object. So it will have it's own connection pool. I had forgotten about that. Anyhow, as far as I can see, there still is no issue.

Owner

simonz05 commented Mar 29, 2012

It does, thanks! But I'm still wondering how I clean up once I'm through using the Client, i.e. at what point the tcp connections in the pool are closed?

They timeout. It might be better to close these explicitly, though.

They timeout. It might be better to close these explicitly, though.

That's what I meant :) I don't suppose it's an issue either, as the typical redis use case would be to keep the connection open for the life of the go application anyway.

Owner

simonz05 commented Mar 29, 2012

That's what I meant :) I don't suppose it's an issue either, as the typical redis use case would be to keep the connection open for the life of the go application anyway.

Yes, in this case it might make more sense to close them. For a synchronous client there is a pool of connections. So you can use the client object in concurrent context. A command will simply pop a connection from the free-pool and push it back when done, but a pipe isn't really safe for concurrent use — since a command modifies its state.

@simonz05 simonz05 reopened this Mar 29, 2012

@simonz05 simonz05 closed this in 73fc4f2 Mar 29, 2012

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