Infinite connection creation loop after session termination

[biinilya]

netstat -tn | grep 9042 | wc -l && go run gocql_demo.go && netstat -tn | grep 9042 | wc -l
0
2013/08/22 13:44:49 failed to connect to "127.0.0.1:9042": dial tcp 127.0.0.1:9042: cannot assign requested address
2013/08/22 13:44:49 failed to connect to "127.0.0.1:9042": dial tcp 127.0.0.1:9042: cannot assign requested address
28231

Sample demo app to reproduce

package main

import (
"time"
"tux21b.org/v1/gocql"
)

func main() {
conn := gocql.NewCluster("build-12-04")
sess := conn.CreateSession()
sess.Close()

time.Sleep(60 * time.Second)

}

[phillipCouto]

Issue #30 could be related to this as once the session closed and fell out of scope the library continued to create new connections.

Nice find!

[tux21b]

Ouch, many thanks for pointing that out. That would also explain Phillip's "cannot assign requested address" error because all ports are already exhausted. I will look into it.

[phillipCouto]

I figured out where the problem is with this. I will write a commit later on today to resolve this issue.

[tux21b]

Please wait with this change. The current implementation is quite hard to follow, because the connection state (connect, delay, reconnect, change keyspace, add to pool) is representation by different goroutines. I have a local implementation of a Host type that manages the connection pool to a single node and doesn't suffer this problem. I will commit it on the weekend.

[phillipCouto]

Ok to solve the issue I just changed cluster.go Line 182 to:

if !c.close {
    go c.connect(conn.Address()) // reconnect
}

This way when the connections throw errors from being forcefully closed the cluster doesn't keep trying to recreate them.

I will hold off on the commit but you can work this in if you feel it is still valid with your upcoming changes.

[tux21b]

Ah, ok. If it's really that simple feel free to commit it (I gave you contributor access to the repo here), but please, do not waste too much time with this at the moment, because the connection pool logic is likely to change anyway.

[phillipCouto]

This issue has been resolved with commit c0c4daf