Remove check for available streams

[miguelvps]

A connection should be pickable even if no streams are currently
available. In this case, when executing the query, the connection will
block reading from the streams channel [see func (c *Conn) exec(...)]
until one is available.

This avoids 'unavailable' errors when there are more than
numConns*numStreams queries pending.

[phillipCouto]

LGTM nice and simple yet the bug has a big impact.

I want to have one more person weigh in on it before we merge.

Thanks for fix!

[tux21b]

LGTM. The previous check was very racy anyway. We should probably add a timeout to the receive from the uniq channel to send a signal to the connection manager that more connections might be required. But that's another issue.

[miguelvps]

Thanks!

[tux21b]

@miguelvps Many thanks for your contribution. I have also added your name and mail address to the AUTHORS file for copyright purposes. I hope that's OK.

[miguelvps]

@tux21b sure!

[Zariel]

The way to solve this will be to have a global semaphore for the cluster but I dont know a good implementation which allows us to change the count dynamically.

[0x6e6562]

@Zariel Are you saying that there is still a bug here?

[Zariel]

No, but thats just the graceful solution, it works really well when there are a static number of nodes and streams but not with dynamic nodes.

[harpreet-sawhney]

The check should not be removed.

The unavailable call should be handled by a higher level
On 02/05/2014 7:46 am, "Ben Hood" notifications@github.com wrote:

@Zariel https://github.com/Zariel Are you saying that there is still a
bug here?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/158#issuecomment-41960728
.

[Zariel]

Im not entirely happy with the previous behaviour which would end up spamming out ErrUnavailable as soon as you saturated connections.

[harpreet-sawhney]

If the connections are saturated then the client should do something about
it, maybe a back off.

Also there is a possibility that this connection is saturated/has long
running queries and maybe there is another connection that can accommodate
the query.

I believe their is a retry mechanism somewhere
On 02/05/2014 7:49 am, "Chris Bannister" notifications@github.com wrote:

Im not entirely happy with the previous behaviour which would end up
spamming out ErrUnavailable as soon as you saturated connections.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/158#issuecomment-41961018
.

[phillipCouto]

Another benefit of the abstracted connection pool. Since gocql with ship
with a simple fixed host list pool this is valid. Other pool types can
check a connection for available streams before returning a connection to
the caller.
On May 1, 2014 6:01 PM, "harpreet-sawhney" notifications@github.com wrote:

If the connections are saturated then the client should do something about
it, maybe a back off.

Also there is a possibility that this connection is saturated/has long
running queries and maybe there is another connection that can accommodate
the query.

I believe their is a retry mechanism somewhere
On 02/05/2014 7:49 am, "Chris Bannister" notifications@github.com
wrote:

Im not entirely happy with the previous behaviour which would end up
spamming out ErrUnavailable as soon as you saturated connections.

—
Reply to this email directly or view it on GitHub<
https://github.com/gocql/gocql/pull/158#issuecomment-41961018>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/158#issuecomment-41962051
.

[harpreet-sawhney]

Streams are evil :)
On 02/05/2014 8:33 am, "Phillip Couto" notifications@github.com wrote:

Another benefit of the abstracted connection pool. Since gocql with ship
with a simple fixed host list pool this is valid. Other pool types can
check a connection for available streams before returning a connection to
the caller.
On May 1, 2014 6:01 PM, "harpreet-sawhney" notifications@github.com
wrote:

If the connections are saturated then the client should do something
about
it, maybe a back off.

Also there is a possibility that this connection is saturated/has long
running queries and maybe there is another connection that can
accommodate
the query.

I believe their is a retry mechanism somewhere
On 02/05/2014 7:49 am, "Chris Bannister" notifications@github.com
wrote:

Im not entirely happy with the previous behaviour which would end up
spamming out ErrUnavailable as soon as you saturated connections.

—
Reply to this email directly or view it on GitHub<
https://github.com/gocql/gocql/pull/158#issuecomment-41961018>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/gocql/gocql/pull/158#issuecomment-41962051>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/158#issuecomment-41964681
.

[phillipCouto]

Haha so I've heard.
On May 1, 2014 6:56 PM, "harpreet-sawhney" notifications@github.com wrote:

Streams are evil :)
On 02/05/2014 8:33 am, "Phillip Couto" notifications@github.com wrote:

Another benefit of the abstracted connection pool. Since gocql with ship
with a simple fixed host list pool this is valid. Other pool types can
check a connection for available streams before returning a connection
to
the caller.
On May 1, 2014 6:01 PM, "harpreet-sawhney" notifications@github.com
wrote:

If the connections are saturated then the client should do something
about
it, maybe a back off.

Also there is a possibility that this connection is saturated/has long
running queries and maybe there is another connection that can
accommodate
the query.

I believe their is a retry mechanism somewhere
On 02/05/2014 7:49 am, "Chris Bannister" notifications@github.com
wrote:

Im not entirely happy with the previous behaviour which would end up
spamming out ErrUnavailable as soon as you saturated connections.

—
Reply to this email directly or view it on GitHub<
https://github.com/gocql/gocql/pull/158#issuecomment-41961018>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/gocql/gocql/pull/158#issuecomment-41962051>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/gocql/gocql/pull/158#issuecomment-41964681>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/158#issuecomment-41966423
.

[miguelvps]

I agree that ideally this should be solved at the connection pool
level, with the possibility of setting a timeout for it to grab a
valid (i.e. with available streams) connection.

The removed check still lets more queries than the available streams
to be assigned to a connection through a race condition. CAS maybe?